컴포넌트?
시스템의 구성요소로 배포할 수 있는 가장 작은 단위
잘 설계된 컴포넌트라면 반드시 독립적으로 배포, 개발 가능해야 한다.
컴포넌트 응집도
- REP(Reuse/Release Equivalence Principle) : 재사용/릴리스 등가 원칙
- CCP(Common Closure Principle) : 공통 폐쇄 원칙
- CRP(Common Reuse Principle) : 공통 재사용 원칙
REP: 재사용/릴리스 등가 원칙
재사용 단위는 릴리스 단위와 같다
단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 동일한 릴리스로 추적 관리되어야 한다.
CCP: 공통 폐쇄 원칙
동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.
단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안된다.
애플리케이션에서 코드가 반드시 변경되어야 할때, 여러 컴포넌트에 분산되어 발생하기보다는, 변경 모두가 단일 컴포넌트에서 발생하는 것이 낫다. 같은 이유로 변경될 가능성이 있는 클래스는 모두 한곳으로 묶는것이 좋다.
CRP: 공통 재사용 원칙
컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.
같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다.
강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다.
결론
어느 클래스들을 묶어서 컴포넌트로 만들지를 결정할 때, 재사용성과 개발가능성이라는 상충하는 힘을 반드시 고려해야한다. 애플리케이션의 요구에 맞게 균형을 잡는 것이 중요하고, 이 균형점은 거의 항상 유동적이다.
컴포넌트 결합
ADP: 의존성 비순환 원칙
컴포넌트 의존성 그래프에 순환이 있어서는 안된다.
숙취 증후군 : 같은 팀에서 더 늦게까지 일한 팀원이 내가 의존하고 있던 무언가를 수정해서 프로그램이 동작하지 않는 상황
해결책 1 : 주 단위 빌드(Weekly Build)
5일 중 4일 동안 각자 개발을 진행하고 마지막 날에 통합하는 방법이다. 프로젝트가 커질수록 통합하는데 소요되는 시간이 길어질 수 있다.
해결책 2 : 순환 의존성 제거하기 - 의존성 비순환 원칙
위의 컴포넌트 구조를 보면 어떤 컴포넌트에서 시작하더라도, 의존성 관계를 따라가면서 최초의 컴포넌트로 되돌아갈 수 없다.
개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한다. 이 절차가 성공적으로 동작하려면 컴포넌트 사이의 의존성 구조를 반드시 관리해야 한다. 의존성 구조에 순환이 있어서는 안된다.
흐트러짐(jitters)
애플리케이션이 성장함에 따라 컴포넌트 의존성 구조는 서서히 흐트러지기 때문에 의존성 구조에 순환이 발생하는지 항상 관찰해야 한다.
하향식(top-down) 설계
컴포넌트 구조는 하향식으로 설계할 수 없다. 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 시스템이 성장하고 변경될 때 함께 진화한다.
아직 아무런 클래스도 설계하지 않은 상태에서 컴포넌트 의존성 구조를 설계하려고 시도하면 상당히 큰 실패를 보게된다.
컴포넌트 의존성 구조는 시스템의 논리적 설계에 발맞춰 성장하고 진화해야한다.
SDP: 안정된 의존성 원칙
안정성의 방향으로(더 안정된 쪽에) 의존하라
변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어서는 안된다. 한번 의존하게 되면 변동성이 큰 컴포넌트도 결국 변경이 어려워진다.
안정된 의존성 원칙을 준수하면 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들 수 있다.
안정성
컴포넌트 안쪽으로 들어오는 의존성이 많아지면 상당히 안정적이라고 볼 수 있다. 사소한 변경이라도 의존하는 모든 컴포넌트를 만족키면서 변경하려면 상당한 노력이 들기 때문이다.
모든 컴포넌트가 안정적이어야 하는 것은 아니다
모든 컴포넌트가 안정적인 시스템이라면 변경이 불가능하다. 변경가능한 컴포넌트가 안정된 컴포넌트에 의존하는 것이 이상적인 구조이다.
SAP: 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
안정된 컴포넌트는 추상화 컴포넌트여야 하고, 이를 통해 안정성이 컴포넌트를 확장하는 일을 방해해서는 안된다.
안정된 컴포넌트라면 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다.
불안정한 컴포넌트는 반드시 구체 컴포넌트여야 하고, 불안정하므로 컴포넌트 내부의 구체적인 코드를 쉽게 변경할 수 있어야한다.
Reference
Clean Architecture - Robert C. Martin
