[Clean Architecture] 컴포넌트 응집도

이번에는 컴포넌트 응집도와 관련된 3가지 원칙을 알아보자.

 

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

 

재사용 단위는 릴리스 단위와 같다

• 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다.
• 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다.
• 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다. (당연한 사실!!)
  • 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 한다.
  • 동일한 릴리스로 추적 관리, 동일한 릴리스 문서에 포함되어야 한다.
• CCP와 CRP는 REP를 엄격하게 제약을 가하는 측면에서 정의한다.

 

 

2. CCP(Common Closure Principle) : 공통 폐쇄 원칙

동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라.
서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라. 

 

 

SRP와 비슷하다는 것이 보이는가???

• 이 원칙은 SRP를 컴포넌트 관점에서 다시 쓴 것.
• 같은 이유로 변경될 가능성이 있는 클래스는 모두 한 곳으로 묶을 것을 권한다.
• 물리적 또는 개념적으로 강하게 결합되어 항상 함께 변경되는 클래스들은 하나의 컴포넌트에 속해야한다. 
  => 소프트웨어를 릴리스, 재검증, 배포하는 일과 관련된 작업량을 최소화할 수 있다.
• 동일한 유형의 변경에 대해 닫혀 있는 클래스들을 하나의 컴포넌트로 묶는다.
  => 변경이 필요한 요구사항이 발생했을 때, 그 변경이 영향을 주는 컴포넌트들이 최소한으로 한정됨.

 

3. CRP(Common Reuse Principle) : 공통 재사용 원칙

컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.

• 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다.
• CRP는 동일한 컴포넌트로 묶어서는 안되는 클래스가 무엇인지도 말해준다.
• 강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다.
  *의존하는 컴포넌트가 있다면 해당 컴포넌트의 모든 클래스에 대해 의존함을 확실히 인지해야한다.
• CRP는 ISP의 포괄적인 버전이다.
  
  • ISP : 사용하지 않는 매서드가 있는 클래스에 의존하지 말 것.
  • CRP : 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말 것.

 

컴포넌트 응집도에 대한 균형 다이어그램

[Clean Architecture] 균형 다이어그램.

응집도에 관한 세 원칙은 서로 상충되는 특징이 있다.

* REP와 CCP는 포함 원칙으로 컴포넌트를 더욱 크게 만든다.

* CRP는 배제 원칙으로 컴포넌트를 더욱 작게 만든다.

따라서 우리는 훌륭한 아키텍트가 되기 위해서 이 원칙들이 균형을 이루는 방법을 찾아야 한다.

 

그래프 설명

• 균형 다이어그램으로, 응집도에 관한 세 원칙이 서로 어떻게 상호작용하는지 보여준다.
• 다이어그램의 각 변은 반대쪽 꼭지점에 있는 원칙을 포기 했을 때, 감수해야 할 비용을 나타낸다.

그래프 해석

• REP와 CRP에만 중점을 두면, 사소한 변경이 생겼을 때, 너무 많은 컴포넌트에 영향을 준다.
  (함께 묶여야하는 것들이 흩어져있으므로)
• CCP와 REP에만 과도하게 집중하면 불필요한 릴리스가 너무 빈번해진다.
  (결합도가 낮은 컴포넌트가 되므로)

프로젝트에서의 의미

• 프로젝트 초기에는 개발 가능성이 재사용성보다 더욱 중요하기 때문에 CCP가 REP보다 훨씬 중요.
• 프로젝트는 삼각형의 오른쪽에서 시작하는 편이며, 이때 오직 재사용성만 희생하면 된다.
• 프로젝트가 성숙하고, 그 프로젝트로부터 파생된 또 다른 프로젝트가 시작되면, 삼각형에서 점차 왼쪽으로 이동.
  => 프로젝트의 컴포넌트 구조는 시간과 성숙도에 따라 변한다.

결론

어느 클래스들을 묶어서 컴포넌트로 만들지를 결정할 때, 재사용성과 개발 가능성이라는 상충하는 힘을 반드시 고려해야 한다. 이들 사이에서 애플리케이션의 요구에 맞게 균형을 잡는 일은 중요하다. 심지어 이 균형점은 거의 항상 유동적이다.

결과적으로 시간의 흐름에 따라 프로젝트의 초점이 개발가능성에서 재사용성으로 바뀌고, 그에 따라 컴포넌트를 구성하는 방식도 조금씩 흐트러지고 또 진화한다.(컴포넌트 결합에서 더 자세히 공부해보자!!)