clean-architecture

14. 컴포넌트 결합

지금부터 다룰 세 가지 원칙은 컴포넌트 사이의 관계를 설명한다.

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

주 단위 빌드

주 단위 빌드는 중간 규모의 프로젝트에는 흔하게 사용된다. 주 단위 빌드를 하는 방법은 다음과 같다.
1. 모든 개발자는 일주일의 첫 4일 동안은 서로를 신경쓰지 않는다.
2. 금요일이 되면 변경된 코드를 모두 통합하여 시스템을 빌드한다.

개발보다 통합에 드는 시간이 늘어나게 된다면 팀의 효율성도 서서히 나빠진다.

개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리하는 것이다.

컴포넌트는 개별 개발자 또는 단일 개발팀이 책임질 수 있는 작업 단위가 된다.

개발자가 해당 컴포넌트가 동작하도록 만든 후, 해당 컴포넌트를 릴리즈하여 다른 개발자가 사용할 수 있도록 만든다.

컴포넌트 사이의 순환을 끊고 의존성을 다시 DAG로 원상복구 하는 일은 언제라도 가능하다.
- 의존성 역전 원칙을 적용한다.
- 모두 의존하는 새로운 컴포넌트를 만든다. 그리고 두 컴포넌트가 모두 의존하는 클래스들을 새로운 컴포넌트로 이동시킨다.

컴포넌트 구조는 하향식으로 설계될 수 없다. 컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 오히려 시스템이 성장하고 변경될 때 함께 진화한다.
컴포넌트 의존성 구조와 같이 큰 단위로 분해된 집단을 관찰하면 시스템의 기능적 측면을 컴포넌트가 어떤 식으로든 표현하리라고 믿는다.
의존성 구조와 관련된 최우선 관심사는 변동성을 격리하는 일이다.
애플리케이션이 계속 성장함에 따라 재사용가능한 요소를 만드는 일에 관심을 기울이기 시작한다. 이 때 공통 재사용 원칙이 영향을 미치기 시작한다.

안정성의 방향으로 의존하라. 설계를 유지하다 보면 변경은 불가피하다.

공통 폐쇄 원칙을 준수함으로써, 컴포넌트가 다른 유형의 변경에는 영향받지 않으면서도 특정 유형의 변경에만 민감하게 만들 수 있다.

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

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

오로지 인터페이스만을 포함하는 컴포넌트를 생성하는 방식이 이상하게 보일 수도 있다. 이러한 컴포넌트에는 실행 가능한 코드가 전혀 없는데? 하지만 자바나 C#같은 정적 타입 언어를 사용할 때 이 방식은 상당히 흔할 뿐만 아니라, 꼭 필요한 전략으로 알려져 있다.

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

안정된 추상화 원칙

이 장에서 설명한 의존성 관리 지표는 설계의 의존성과 추상화 정도가 내가 훌륭한 패턴이라고 생각하는 수준에 얼마나 잘 부합하는지를 축정한다.

경험을 통해 좋은 의존성도 있지만 좋지 않은 의존성도 있다는 사실을 배웠다고 한다.

이 패턴은 이러한 경험을 반영한다. 하지만 지표는 신이 아니다. 지표는 아무리 해도 불완전하지만, 무언가 유용한 것을 찾을 수 있기를 바란다.