[Clean Architecture 정리] 22장. 클린 아키텍처
독립성
육각형 아키텍처, DCI, BCE 등 여러 아키텍처들이 개발되었지만
⇨ 아키텍처와 관련된 아이디어들의 공통적인 목표는 계층 분리를 통한 관심사 분리(separation of concerns)다.
(단, 최소한의 업무 규칙 계층, 사용자와 시스템 인터페이스 계층을 반드시 포함)
아키텍처는 시스템이 다음과 같은 특징을 지니도록 만듦.
- 프레임워크 독립성
아키텍처는 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 프레임워크가 지닌 제약사항안으로 시스템을 욱여 넣는게 아닌 프레임워크를 도구로 사용할 수 있다. - 테스트 용이성
업무 규칙은 UI, 데이터베이스, 웹 서버, 외부 요소 없이 테스트할 수 있다. - UI 독립성
시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변경하지 않고도 웹 UI를 콘솔 UI로 대체할 수 있다. - 데이터베이스 독립성
오라클이나 MS SQL서버를 몽고DB(MongoDB), 빅테이블(BigTable), 카우치DB(CauchDB) 등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성
실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.
위 다이어그램은 아키텍처들 전부를 실행 가능한 하나의 아이디어로 통합하려는 시도다.
의존성 규칙
안으로 향할수록 고수준의 소프트웨어가 된다.
바깥쪽 원은 메커니즘이고, 안쪽 원은 정책이다.
이러한 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙이다.
소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.
내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다.
함수, 클래스, 변수, 소프트웨어 엔티티로 명명되는 모든 것을 언급해선 안된다.
외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다.
엔티티
엔티티는 전사적인 핵심 업무 규칙을 캡슐화함.
엔티티 = 핵심 업무 규칙 + 핵심 업무 데이터 OR 메서드만 가진 객체
운영 관점에서 특정 애플리케이션에 어떤 것이 변경이 필요하더라도 엔티티에 영향을 주어선 안 된다.
유스케이스
유스케이스는 애플리케이션에 특화된 업무 규칙을 캡슐화한다.
유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티의 핵심 업무 규칙을 사용해서 목적을 달성한다.
외부의 어떤 것도 유스케이스에 영향을 주면 안되며, 유스케이스 또한 내부의 엔티티에 영향을 주어선 안 된다.
운영 관점에서 애플리케이션이 변경된다면 유스케이스는 영향을 받으며, 소프트웨어 또한 영향을 받게 된다.
인터페이스 어댑터
인터페이스 어댑터 계층은 일련의 어댑터로 구성된다.
인터페이스 어댑터는 엔티티나 유스케이스에서 가장 편리한 형식을 외부 에이전시에서 가장 편리한 형식으로 변환한다.
MVC 아키텍처를 포괄하며, Presenter, View, Controller는 모두 인터페이스 계층에 속한다.
프레임워크와 드라이버
데이터베이스나 웹 프레임워크와 같은 프레임워크, 도구들로 구성된다.
모든 세부사항이 위치한 곳이며 이러한 세부사항의 변경이 내부에 영향을 끼치는 것을 최소화한다.
원은 네 개여야만 하나?
중요한 것은 이러한 계층의 수가 아닌 의존성 규칙이다.
소스 코드 의존성을 항상 원 내부로 향해야 한다.
원 내부로 향할수록 추상화와 정책의 수준은 높아지고 외부로 갈수록 저수준의 구체적인 세부사항이다.
경계 횡단하기
유스케이스 계층과 인터페이스 어댑터 계층(Presenter, Controller)와 통신할 때, 제어의 흐름은 고수준에서 저수준으로 향하게 된다.
이런 경우, 의존성 역전 원칙을 사용해 해결할 수 있다.
인터페이스와 상속을 이용한다면 제어 흐름이 경계를 가로지르는 지점에서 소스 코드의 의존성과 제어 흐름을 반대로 만들 수 있다.
경계를 횡단하는 데이터는 어떤 모습인가
경계를 가로지르는 데이터는 간단한 데이터 구조로 이루어진다.
데이터 구조가 다른 계층에 의존성을 가진다면 다른 계층의 변경을 영향을 함께 가져갈 것이다.
경계를 가로질러 데이터를 전달할 때는, 내부 원에서 사용하기 편리한 형태로 전달해야 한다.
전형적인 시나리오
의존성 방향에 주목하라.
모든 의존성은 경계선을 안쪽으로 가로지르며, 따라서 의존성 규칙을 수행한다.
결론
소프트웨어를 계층으로 분리하고 의존성 규칙을 준수하면 본질적으로 테스트하기 쉬운 시스템을 만들게 되며, 시스템의 외부 요소가 구식이 되더라도 쉽게 교체할 수 있다.
