- 육각형 아키텍처
- 포트와 어댑터라고도 알려져 있는 아키텍처로 외부에서 내부로 의존성이 향하고 각 계층에는 포트와 어댑터가 존재함
- DCI: Data, Context and Interaction
- BCE: Boundary-Control-Entity
세 개의 아키텍처 모두 세부적인 면에서는 차이가 있어도 이들 모두의 목표는 관심사의 분리이다. 세 아키텍처 모두 소프트웨어를 계층으로 분리해 관심사 분리의 목표를 달성한다.
아키텍처의 목표
- 프레임워크 독립성
- 테스트 용이성
- UI 독립성
- 데이터베이스 독립성
- 모든 외부 에이전시에 대한 독립성
의존성 규칙
모든 의존성은 프레임워크와 드라이버 -> 인터페이스 어댑터 -> 애플리케이션 업무 규칙 (유스케이스) -> 엔터프라이즈 업무 규칙 (엔티티) 방향을 따라야 한다.
엔티티
엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다. 엔티티는 메서드를 가지는 객체이거나 데이터 구조와 함수의 집합일 수도 있다. 재사용 가능하다면 형태는 중요하지 않다. 외부의 무언가가 변경되더라도 엔티티가 변경될 가능성은 굉장히 낮다. 외부에 어떤 변화가 있더라도 이 변화가 엔티티에 영향을 주면 안된다.
유스케이스
유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함한다. 엔티티를 직접 다루고, 유스케이스의 변경 사항이 엔티티에 영향을 끼쳐서는 안된다. 또한 데이터베이스나 UI 등 외부 변경이 유스케이스에 영향을 주어서도 안된다.
애플리케이션이 변경된다면 유스케이스가 영향을 받고, 세부사항이 변하면 코드의 변경이 있을 수 있다.
인터페이스 어댑터
어댑터로 구성되어 데이터를 유스케이스와 엔티티에게 가장 편리한 형식에서 데이터베이스나 웹 같은 외부 에이전시에 가장 편리한 형식으로 변환한다. 데이터베이스나 프레임워크와 같은 외부 계층에 대해서 알지 않아야 하고, 각 세부사항은 더 외부에서 구현해야 한다.
프레임워크와 드라이버
가장 바깥쪽 계층으로 일반적으로 데이터베이스나 웹 프레임워크가 위치한다. 인터페이스 어댑터에 맞춘 세부 사항을 구현하고, 여기서의 변화나 추가 사항이 내부로 전파되지 않아야 한다.
모든 것의 핵심은 내부(엔티티 방향)로 변화 또는 추가가 전파되지 않아야 한다는 점이다. 내부로 들어갈수록 변화하지 않고 안정적이어야 하고, 외부로 갈수록 쉽게 변화 가능하고 유동적이어야 한다.
각 경계를 횡단할 때는 엔티티 또는 데이터베이스의 로우를 그대로 사용하려는 유혹을 피해야 한다. 데이터를 횡단하는 객체 또는 자료구조를 별도로 사용하여 의존성이 항상 안쪽으로 향하도록 유지해야 한다.
