컴포넌트 결합
14. 컴포넌트 결합
ADP: 의존성 비순환 원칙(Acyclic Dependencies Principle)
컴포넌트 의존성 그래프에 순환이 있어서는 안 된다.
많은 개발자가 동일한 소스 파일을 수정하는 환경에서 문제 발생
해결책: 주 단위 빌드, 순환 의존성 제거
주 단위 빌드(Weekly Build)
5일 중 4일 동안 각자 개발/1일 동안 머지
프로젝트가 커질수록 통합이 늦어짐
빌드 주기가 계속 늦어지게 됨
순환 의존성 제거하기
개발 환경을 릴리스 가능한 컴포넌트 단위로 분리하는 것
릴리스 관리 -> 어떤 팀도 다른 팀에 의해 좌우되지 않음
시스템 전체를 릴리스해야 할 때가 오면 릴리스 절차는 상향식으로 진행
순환이 컴포넌트 의존성 그래프에 미치는 영향
순환이 생기면 해당 컴포넌트들은 사실상 하나의 거대한 컴포넌트가 됨
순환이 생기면 컴포넌트를 분리하기가 상당히 어려워 짐
순환이 생기면 컴포넌트를 어떤 순서로 빌드해야 올바를지 파악하기가 상당히 힘들어 짐
순환 끊기
- 의존성 역전 원칙(DIP) 적용
인터페이스를 통해 의존성을 역전하여 순환을 끊음
- 순환 컴포넌트가 모두 의존하는 새로운 컴포넌트를 만든다
흐트러짐(Jitters)
요구사항이 변경되면 컴포넌트 구조도 변경될 수 있음
하향식(top-down) 설계
컴포넌트 구조는 하향식으로 설계될 수 없다.
컴포넌트 의존성 다이어그램은 애플리케이션의 기능을 기술하는 일과는 거의 관련이 없다.
오히려 컴포넌트 의존성 다이어그램은 애플리케이션의 빌드 가능성과 유지보수성을 보여주는 지도와 같다.
바로 이러한 이유때문에 컴포넌트 구조는 프로젝트 초기에 설계할 수 없다.
의존성 구조와 관련된 최우선 관심사는 변동성을 격리하는 일
컴포넌트 의존성 그래프는 자주 변경되는 컴포넌트로부터 안정적이며 가치가 높은 컴포넌트를 보호하려는 아키텍트가 만들고 가다듬게 됨
아무런 클래스도 설계하지 않은 상태에서 컴포넌트 의존성 구조를 설계하려고 하면 상당히 큰 실패를 맛볼 수 있다.
컴포넌트 의존성 구조는 시스템의 논리적 설계에 발맞춰 성장하며 또 진화해야 한다.
SDP: 안정된 의존성 원칙
안정성의 방향으로(더 안정된 쪽에) 의존하라
컴포넌트 중 일부는 변동성을 지니도록 설계됨
변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어서는 절대로 안 됨
변경하기 쉬운 모듈에 누군가가 의존성을 달아 버리면 당신의 모듈도 변경하기 어려워진다.
안정성(stability)
안정성은 변화가 발생하는 빈도와는 직접적인 관련이 없다.
안정성은 변경을 만들기 위해 필요한 작업량과 관련된다.
소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법 하나는 수많은 다른 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것
책임진다(responsible): 자신에게 의존하는 컴포넌트들을 책임짐
독립적(independent): 자신이 의존하는 컴포넌트가 없음
안정성 지표
Fan-in: 안으로 들어오는 의존성
Fan-out: 바깥으로 나가는 의존성
I(불안정성): I = Fan-out / (Fan-in + Fan-out)
I=0이면 최고로 안정된 컴포넌트
I=1이면 최고로 불안정한 컴포넌트
컴포넌트의 I지표는 그 컴포넌트가 의존하는 다른 컴포넌트들의 I보다 커야한다.
의존성 방향으로 갈수록 I지표 값이 감소해야 한다.
모든 컴포넌트가 안정적이어야 하는 것은 아니다
모든 컴포넌트가 최고로 안정적인 시스템이라면 변경이 불가능
불안정 컴포넌트에 의존 X
추상 컴포넌트
추상 컴포넌트는 상당히 안정적이며, 따라서 덜 안정적인 컴포넌트가 의존할 수 있는 대상
SAP: 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
고수준 정책을 어디에 위치시켜야 하는가?
추상 클래스를 통해 안정된 상태이면서도 변경에 대응가능하도록 함
안정된 추상화 원칙
안정된 추상화 원칙은 안정성과 추상화 정도 사이의 관계를 정의
안정된 컴포넌트는 추상 컴포넌트여야 하며, 이를 통해 안정성이 컴포넌트를 확장하는 일을 방해해서는 안 된다고 말함
불안정한 컴포넌트는 반드시 구체 컴포넌트여야 한다고 말함
SAP와 SDP를 결합하면 컴포넌트에 대한 DIP나 마찬가지
추상화 정도 측정하기
- Nc: 컴포넌트의 클래스 개수
- Na: 컴포넌트의 추상 클래스와 인터페이스의 개수
- A: 추상화 정도, A = Na / Nc
주계열
안정성(I)와 추상화 정도(A) 사이의 관계를 정의
I - A 그래프를 통해 배제할 구역 추론
고통의 구역
(0, 0) 주변 구역에 위치한 컴포넌트
안정적이며 구체적 / 확장 불가, 변경도 어려움
ex. 데이터베이스 스키마, String
String 처럼 변동성이 없다면 해롭지 않다.
쓸모없는 구역
(1, 1) 주변의 컴포넌트
추상적이지만, 의존하지도 않음 -> 폐기물
배제 구역 벗어나기
주 계열: (1,0) 과 (0,1)을 잇는 선분
컴포넌트가 위치할 수 있는 가장 바람직한 지점 -> 주 계열의 종점
주계열에 가까울 수록 이상적
주계열과의 거리
- D: 거리 , D=|A+I-1|
D 지표를 계산한 후에 컴포넌트 재검토 가능
시간에 따라 D 지표를 확인하여 이상한 징후가 생겼는지 확인 가능
참조
- 클린 아키텍처(Clean Architecture)