[Clean Architecture] 14장 :: 컴포넌트 결합

📕 ADP: 의존성 비순환 원칙

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

대규모 프로젝트에서 서로 의존하는 부분을 다른 사람이 건들여서 숙취 증후군이 발생한다.

이 문제의 해결책으로 다음 두 가지 방법이 있다.

• 주 단위 빌드(weekly build)
• 의존성 비순환 원칙(Acyclic Dependencies Principle, ADP)

📍 주 단위 빌드(Weekly Build)

• 중간 규모의 프로젝트에서 흔히 사용
• 일주일의 첫 4일을 각자 코딩하고 금요일에 통합 및 빌드를 몰아서 한다.
• 장점
  • 빠른 피드백
  • 고립되어 편안하게 개발 가능
• 단점
  • 프로젝트가 커지면 통합하는데 오래 걸림
  • 통합에 드는 시간이 늘어나면 팀의 효율성이 나빠짐

📍 순환 의존성 제거하기

개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한다.

• 특정 컴포넌트가 변경되더라도 다른 팀에 즉각적으로 영향을 주지 않고 해당 릴리즈를 반영할 시간을 준다.

이 절차를 위해서 의존성 구조에 순환이 없도록 관리한다.

• 이 구조는 방향 그래프(directed graph)이다.
• 컴포넌트는 정점(vertext)에 해당하고, 의존성 관계는 방향이 있는 간선(directed edge)에 해당한다.
• 어느 컴포넌트에서 시작하든, 의존성 관계를 따라가면서 최초의 컴포넌트로 돌아갈 수 없다.
• 이 구조는 비순환 방향 그래프(Directed Acyclic Graph, DAG)다.
• 컴포넌트 구성요소 간 의존성을 파악하고 있으면 시스템을 빌드하는 방법과 순서를 알 수 있다.

📍 순환이 컴포넌트 의존성 그래프에 미치는 영향

• 순환을 하면서 사실상 하나의 거대한 컴포넌트가 되어 버린다.
• 의존성 그래프에 순환이 생기면 컴포넌트를 분리하기가 상당히 어려워진다.
• 단위 테스트에 어려움을 겪고, 에러가 쉽게 발생한다.
• 모듈이 증가하면서 빌드 이슈가 발생한다.

📍 순환 끊기

1. 의존성 역전을 이용
2. 순환 하는 부분 모두가 의존하는 새로운 컴포넌트를 만들고, 의존하는 클래스들을 새로운 컴포넌트로 이동시킨다.

📍 흐트러짐

요구사항이 변경되면 컴포넌트 구조도 변경될 수 있다.
→ 새로운 컴포넌트를 생성하거나 의존성 구조가 더 커질 수도 있음을 의미한다.

📗 하향식(top-down) 설계

• 컴포넌트 구조는 하향식으로 설계될 수 없다.
  • 컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니다.
• 컴포넌트 의존성 다이어그램은 애플리케이션의 빌드 가능성(buuildability)과 유지보수성(maintainability)을 보여주는 지도(map)와 같다.
• 의존성 구조와 관련된 최우선 관심사는 변동성을 격리하는 일이다.
• 아키텍트는 컴포넌트 의존성 그래프를 자주 변경되는 컴포넌트로부터 안정적으로 만든다.
• 컴포넌트 의존성 구조는 시스템의 논리적 설계에 맞춰 성장해야 한다.

📙 SDP: 안정된 의존성 원칙

📘

📒

📕

📚 Reference

• Clean Architecture : 소프트웨어 구조와 설계의 원칙