Clean Architecture 정리 – 5부 19장 아키텍처: 정책과 수준

소프트웨어 시스템 내부에서의 정책

• '정책'이란 입력을 출력으로 바꾸는 로직을 의미함
• 소프트웨어 시스템은 입력을 출력으로 바꾸는 '정책'을 코드로 구현한 것

 

 

정책과 의존성 방향

• 아키텍처는 정책이 변경되는 이유와 시점을 기준으로 컴포넌트를 나눠야 함
• 동일한 이유, 동일한 시점에 변경되는 정책은 동일한 수준의 컴포넌트에 속해야 함
• 서로 다른 이유, 다른 시점에 변경되는 정책은 반드시 분리된 컴포넌트로 구성해야 함

 

 

의존성 그래프 구조

• 시스템은 정점(node)과 간선(edge)으로 이루어진 방향 비순환 그래프(DAG)로 표현됨
• 정점은 동일한 수준의 컴포넌트, 간선은 컴포넌트 간의 의존성을 의미함
• 의존성 방향은 낮은 수준에서 높은 수준으로만 흐르도록 구성해야 함.

 

 

수준

• '수준(level)'이란 입력과 출력까지의 거리를 의미함
• 입력이나 출력을 직접 다루는 컴포넌트는 시스템에서 가장 낮은 수준에 위치함
• 입력/출력으로부터 멀리 떨어져 순수한 알고리즘만 수행하는 컴포넌트는 가장 높은 수준에 해당함

 

 

예시: 간단한 번역 프로그램

• '문자 읽기', '문자 쓰기'는 입출력 장치에 가까우므로 저수준 컴포넌트임
• '번역'은 순수한 알고리즘만 수행하므로 고수준 컴포넌트임

 

소스코드 상 의존성은 저수준 → 고수준 방향으로만 연결되어야 함

문자 읽기 → 번역 ← 문자 쓰기 (소스 코드 의존성)

 

데이터 흐름과 소스 코드 의존성은 다를 수 있음

문자 읽기 → 번역 → 문자 쓰기 (데이터 흐름)

👉 소스 코드 의존성은 수준(level)을 기준으로 결정해야 하며, 데이터 흐름(data flow)을 기준으로 결정하면 안 됨

 

 

 

아키텍처 흐름 예시

이 설계 방식의 특징

• 인터페이스를 경계로 고수준과 저수준을 분리함
• 입출력 장치가 변경되어도 고수준 정책(Translator)에는 영향이 없음
• 고수준 정책을 다른 맥락에서도 재사용 가능함
• 변경이 발생해도 전파 범위가 제한됨
• 다음의 원칙들과 부합함:
  • 단일 책임 원칙 (SRP)
  • 공통 폐쇄 원칙 (CCP: Common Closure Principle - 함께 변경되는 클래스는 하나의 컴포넌트에 포함되어야 함)
  • 의존 역전 원칙 (DIP)
  • 개방 폐쇄 원칙 (OCP)

 

 

컴포넌트 수준으로 정리하면

• 저수준 컴포넌트가 고수준 컴포넌트에 플러그인되는 형태로 구성

 

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 19장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.