[Clean Architecture 정리] 14장. 컴포넌트 결합 (2)

하향식(top-down) 설계

컴포넌트 의존성 다이어그램은 애플리케이션 기능 기술보다 빌드 가능성(buildability)과 유지 보수성(maintainability)를 보여주는 지도와 같다.

따라서, 컴포넌트 구조는 초기에 설계할 수 없고 시스템이 성장하고 변경될 때 함께 진화하기 때문에 하향식 설계될 수 없다. 

 

 

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

- "안정성의 방향으로 의존하라"

- 설계는 결코 정적일 수 없으며 설계를 유지하다보면 변경은 불가능하다.

- 변경이 쉽지 않은 컴포넌트가 변경이 예상되는 컴포넌트에 의존하게 만들면 안된다.

 

 

안정성

- 안정성은 변경을 만들기 위해 필요한 비용과 관련이 있다. 변경을 위한 비용이 크다면 안전하다고 말할 수 있다.

- 소프트웨어 컴포넌트를 변경하기 어렵게 만드는 요인에는 컴포넌트 크기, 복잡도, 간결함 등이 있으며 그 중 가장 확실한 요인은 수 많은 다른 컴포넌트가 의존하도록 만드는 것이다.

 

 

안정된 컴포넌트

- 안정된 컴포넌트는 해당 컴포넌트를 의존하는 컴포넌트들을 책임진다(responsible)라고 말하며, 다른 컴포넌트의 변경이 영향이 없기 때문에 독립적이다(independent)라고 말할 수 있다.

 

 

불안정한 컴포넌트

- 반대로 불안정된 컴포넌트는 의존하는 컴포넌트들에 책임이 없다고 말하며, 다른 컴포넌트의 변경에 영향을 받기 때문에 의존적이라고 말할 수 있다.

 

 

 

안정성 지표

- 컴포넌트로 들어오고 나가는 의존성의 개수를 지표로 사용할 수 있다.

- Fan-in : 안으로 들어오는 의존성. 컴포넌트 내부 클래스에 의존하는 컴포넌트 외부 클래스의 개수

- Fan-out : 바깥으로 나가는 의존성. 컴포넌트 외부 클래스에 의존하는 컴포넌트 내부 클래스의 개수

- I (불안정성) = Fan-out / (Fan-in + Fan-out) : [0, 1]의 범위를 가지며, I = 0일 때 최고로 안정된, I = 1일 때 최고로 불안정된 컴포넌트라 말한다.

 

 

a. 최고로 안정된 컴포넌트 ( I = 0 )

- 해당 컴포넌트를 의존하는 다른 컴포넌트는 있지만, 해당 컴포넌트는 다른 컴포넌트를 의존하지 않는 경우

- 해당 컴포넌트는 다른 컴포넌트를 책임지고, 독립적이다.

- 자신에게 의존하는 컴포넌트로 인해 변경은 어렵지만, 변경을 강제하는 의존성을 가지고 있지 않는다.

 

 

b. 최고로 불안정된 컴포넌트 ( I = 1 )

- 어떤 컴포넌트도 해당 컴포넌트를 의존하지 않지만, 해당 컴포넌트는 다른 컴포넌트를 의존하는 경우

- 해당 컴포넌트는 책임성이 없으며, 의존적이다.

- 자신에게 의존하는 컴포넌트가 없기 때문에 변경하지 말아야할 이유는 없지만, 다른 컴포넌트의 변경이 해당 컴포넌트의 변경을 강제할 수 있다.

 

 

c. SDP에서 I 지표

- I 지표는 어떤 컴포넌트가 의존하는 다른 컴포넌트보다 커야한다.

- 즉, 의존성 방향으로 갈수록 I 지표는 감소해야 한다.

 

 

 

모든 컴포넌트가 안정적이어야 하는 것은 아니다.

- 모든 컴포넌트가 최고로 안정적이라면 이는 변경이 불가능한 시스템을 의미한다.

- 관례적으로 불안정한 컴포넌트를 위로 두는데, 이는 의존성 방향이 위로 향할 때 SDP를 위배하는 상태가 되기 때문이다.

 

 

 

추상 컴포넌트

- 추상 컴포넌트는 오로지 인터페이스만 포함하는 컴포넌트이다.

- 추상 컴포넌트는 상당히 안정적이며, 덜 안정적인 컴포넌트가 의존할 수 있는 이상적인 대상이다.

 

 

 

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

- "컴포넌트는 안정된 정도만큼만 추상화되어야 한다."

 

 

 

고수준 정책의 위치

- 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경되어선 안된다.

- 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다.

- 하지만, 고수준 정책을 안정된 컴포넌트에 위치시켜면 정책을 포함하는 소스 코드의 변경이 어려워지고 시스템 전체 아키텍처의 유연성을 잃는다.

- 최고로 안정된 컴포넌트 (I=0)를 유지하면서 변경에 유연하게 대응하기 위해선 추상 클래스를 이용한 개방 폐쇄 원칙(OCP)를 적용할 수 있다.

 

 

 

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

- 안정된 추상화 원칙은 안정성(stability)과 추상화(abstraction) 정도 사이의 관계를 정의한다.

- 안정된 컴포넌트는 추상 컴포넌트, 불안정된 컴포넌트는 구체 컴포넌트여야 한다.

- 안정적인 컴포넌트라면 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다.

 

 

 

추상화 정도 측정

- Nc : 컴포넌트의 클래스 개수

- Na : 컴포넌트의 추상 클래스와 인터페이스 개수

- A = Na / Nc : 추상화 정도. [0, 1]의 범위를 가지며, A=0일때 구체 클래스만 포함하는 경우, A=1일때 추상 클래스만을 포함하는 경우를 의미

 

 

 

주계열 (Main Sequence)

 

- 위 그래프는 안정성(I)와 추상화 정도(A) 사이의 관계를 나타내는 그래프이다.

- (0, 1) 일 때, 최고로 안정적이며 추상화된 컴포넌트, (1, 0) 일 때, 최고로 불안정적이며 구체화된 컴포넌트라 말할 수 있다.

- 모든 컴포넌트가 (0, 1) 또는 (1, 0)에 위치하도록 강제할 수 없기 때문에 적절한 합의 지점을 찾아야하는데 (0, 1) - (1, 0) 사이를 잇는 궤적이 해당 지점 주계열 (Main Sequence)가 된다.

- 이 궤적은 배제할 구역(Zone of Exclusion)을 찾는 방식으로 추론될 수 있다.

 

 

 

고통의 구역 (Zone of Pain)

- 매우 안정적이며 구체적인 컴포넌트

- 추상적이지 않아 확장할 수 없고, 안정적이므로 변경하기도 어렵다.

- 변동성이 있는 컴포넌트의 경우 고통의 구역에서 문제가 된다.

 

 

 

쓸모없는 구역 (Zone of Uselessness)

- 최고로 추상적이지만, 어떤 컴포넌트도 의존하지 않는 컴포넌트

- 어떤 클래스도 상속받아 구현하지 않는 추상 클래스가 많은 경우로 제거되어야할 대상일 수 있다.

 

 

 

배제 구역 (Zone of Exclusion) 벗어나기

- 변동성이 큰 컴포넌트는 두 배제 구역에서 벗어나 주계열(Main Sequence) 위 또는 근처에 위치하도록 변경해야 한다.

 

 

 

주계열과의 거리

- 이상적인 상태로부터 컴포넌트가 얼마나 멀리 떨어져있는가를 측정하는 지표

- D = |A + 1 - 1| : [0, 1] 범위의 거리. D=0일 때, 주계열 바로 위에 위치, D=1일 때, 주계열로부터 가장 멀리 위치하는 것을 의미

- D 값이 0에 가깝지 않는 컴포넌트가 있다면 해당 컴포넌트를 재구성할 수 있다.

- D 지표의 평균과 분산이 0에 가까워 질수록 컴포넌트들이 주계열에 위치하도록 설계되었다는 의미

- D 지표의 분산은 '관리 한계(control limit)'을 결정하는 수단으로 사용되어 '극히 예외적인' 컴포넌트를 식별할 수 있다.

 

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24