클린 아키텍처
22. 클린 아키텍처
시스템 아키텍처와 관련된 여러가지 아이디어
- 육각형 아키텍처(Hexagonal Architecture)
- DCI(Data, Context and Interaction)
- BCE(Boundary-Control-Entity)
이들의 목표는 관심사의 분리(separation of concerns)
이들 아키텍처는 모두 시스템이 다음과 같은 특징을 지니도록 만든다.
- 프레임워크 독립성
- 테스트 용이성
- UI 독립성
- 데이터베이스 독립성
- 모든 외부 에이전시에 대한 독립성
의존성 규칙
아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙(dependency rule)이다.
소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.
내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다.
같은 이유로, 외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다.
엔티티
엔티티는 전사적인 핵심 업무 규칙을 캡슐화
운영 관점에서 특정 애플리케이션에 무언가 변경이 필요하더라도 엔티티 계층에는 절대로 영향을 주어서는 안 됨
유스케이스
유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함한다.
유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하며, 엔티티가 자신의 핵심 업무 규칙을 사용해서 유스케이스의 목적을 달성하도록 이끈다.
인터페이스 어댑터
어댑터는 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에게 가장 편리한 형식으로 변환됨
프레젠터(presenter), 뷰(view), 컨트롤러(controller)는 모두 인터페이스 어댑터 계층에 속한다.
이 계층은 데이터를 엔티티와 유스케이스에게 가장 편리한 형식에서 영속성용으로 사용 중인 임의의 프레임워크가 이용하기에 가장 편리한 형식으로 변환
이 계층에는 데이터를 외부 서비스와 같은 외부적인 형식에서 유스케이스나 엔티티에서 사용되는 내부적인 형식으로 변환하는 또 다른 어댑터가 필요하다.
프레임워크와 드라이버
이 계층에서는 안쪽 원과 통신하기 위한 접합 코드 외에는 특별히 더 작성해야 할 코드가 그다지 많지 않다.
모든 세부사항이 위치하는 곳
원은 네 개여야만 하나?
항상 네 개만 사용해야 한다는 규칙은 없다.
하지만 어떠한 경우에도 의존성 규칙은 적용된다.
안쪽으로 이동할수록 소프트웨어는 점점 추상화되고 더 높은 수준의 정책들을 캡슐화한다.
따라서 가장 안쪽 원은 가장 범용적이며 높은 수준을 가진다.
경계 횡단하기
제어흐름은 컨트롤러에서 시작해서, 유스케이스를 지난 후, 프레젠터에서 실행되면서 마무리
소스 코드 의존성은 유스케이스를 향해 안쪽을 가리킨다.
제어흐름과 의존성의 방향이 명백히 반대여야 하는 경우, 대체로 의존성 역전 원칙을 사용하여 해결
경계를 횡단하는 데이터는 어떤 모습인가
흔히 간단한 데이터 구조
격리되어 있는 간단한 데이터 구조가 경계를 가로질러 전달됨
경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기에 가장 편리한 형태를 가져야 함
결론
소프트웨어를 계층으로 분리하고 의존성 규칙을 준수한다면 본질적으로 테스트하기 쉬운 시스템을 만들게 될 것이며, 그에 따른 이점을 누릴 수 있다.
참조
- 클린 아키텍처(Clean Architecture)