Clean Architecture - Component

컴포넌트 응집도

재사용/릴리스 등가 원칙(Reuse/Release Equivalence Principle, REP)

• 재사용 단위는 릴리스 단위와 같다.
• 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 한다.
• 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다.
  (같은 버전 번호, 동일한 릴리스, 동일한 릴리스 문서)
• 아래의 CCP, CRP는 REP를 엄격하게, 하지만 제약을 가하는 측면에서 정의한다.

공통 폐쇄 원칙(Common Closure Principle, CCP)

• 동일한 이유로 동일한 시점에 변경되는 클래스끼리 같은 컴포넌트로 묶는다.
• SRP의 컴포넌트 관점.
• 동일한 유형의 변경에 대해 닫혀있는 클래스들을 하나의 컴포넌트로 묶음으로써 OCP를 컴포넌트 단위로 확대 적용한다.

공통 재사용 원칙(Common Reuse Principle, CRP)

• 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.
• 강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다.
• ISP에 포괄적인 버전.

컴포넌트 응집도의 균형

• 세 가지 원칙들이 균형을 이루는 방법을 찾아야 한다.

  • REP, CRP > CCP : 컴포넌트 변경이 빈번해짐.
  • CRP, CCP > REP : 재사용이 어려움.
  • CCP, REP > CRP : 불필요한 릴리스가 너무 빈번함.

• 프로젝트 흐름에 따른 응집도의 변화

  • 프로젝트 초기 : CCP > CRP > REP (개발 가능성이 중요)
  • 프로젝트 성숙 후 : CCP < CRP < REP (재사용성이 중요)

컴포넌트 결합

의존성 비순환 원칙(Acyclic Dependencies Principle, ADP)

• 컴포넌트 의존성 그래프에 순환이 있어서는 안된다.

• 순환이 발생한 컴포넌트들은 서로에게 얽매이게 되어 다양한 문제가 발생하게 된다.

  1. 의존하게된 모든 컴포넌트들은 동일한 릴리스를 사용해야 한다.
  2. 컴포넌트를 분리하기 어려워진다.
  3. 단위테스트와 릴리스가 어려워진다.
  4. 에러가 쉽게 발생한다.
  5. 빌드 순서를 파악하기 어려워진다.

• 의존성 순환을 끊는 방법

  1. 의존성 역전 원칙(DIP)를 사용한다.
  2. 공통의로 의존하는 새로운 컴포넌트를 만들고 의존하는 클래스들을 이동시킨다.

• 요구사항이 변경되면 의존성 구조도 변경될 수 있기 때문에 순환이 발생하는지는 관찰하며 이를 끊어내야 한다.

• 컴포넌트는 시스템이 성장하고 변경될 때 함께 진화하기 때문에 미리 설계할 수 없다.

안정된 의존성 원칙(Stable Dependencies Principle, SDP)

• 더 안정적인 컴포넌트의 방향으로 의존하라.
• 안정성: 외부를 향하는 의존성보다 내부로 향하는 의존성이 많은 상태를 안정성이 높다고 본다.
• 모든 컴포넌트가 안정적일 필요는 없지만 덜 안정적인 컴포넌트가 더 안정적인 컴포넌트를 의존하는 방향이 바람직하다. (변동성이 낮기 때문)

안정된 추상화 원칙(Stable Abstractions Principle, SAP)

• 컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
• 불안정한 컴포넌트는 내부의 구체적인 코드를 쉽게 변경할 수 있는 구체 컴포넌트여야 한다.
• 안정적인 컴포넌트는 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다.
• 의존성은 추상화의 방향으로 향해야 한다.
• 올바르지 않은 컴포넌트의 예
  1. 안정적이면서 구체적인 컴포넌트(고통의 구역)
     많은 컴포넌트들이 의존하고 있는데 추상화 되어 있지 않아 변경할 때마다 고통스럽다.
  2. 불안정하면서 추상적인 컴포넌트(쓸모 없는 구역)
     변경이 쉽도록 추상화 되어 있지만 어떤 컴포넌트도 의존하지 않으므로 쓸모 없다.