Hexagonal Architecture
Presentation -> Service -> Infra 의 방향으로 의존성이 설계된 MVC 아키텍처에서는 인프라의 변화가 곧 뷰의 변화로 이어지기 쉽다.
그러나 웹 서비스의 핵심은 인프라가 아닌, 실제 비즈니스 로직이 수행되는 서비스 계층이며 더 정확하게는 개발팀의 의사소통 단위가 되는 도메인 객체들이다.
그렇기 때문에 우리가 알던 레이어드 아키텍처와는 의존성의 방향이 다르다. 헥사고날 아키텍처는 앞서 포스팅 했던 클린 아키텍처와 마찬가지로 의존성이 없는 도메인 객체들이 존재하고, 이들에 의존하는 도메인 서비스 계층 또는 usecase 계층이 존재한다.
서비스 계층에서 수행되는 로직들은 외부와 연결된 포트를 통해 외부로 전달되며, 인프라는 포트에 의존한다. 즉, 외부와의 통신을 인터페이스로 추상화하여 비즈니스 로직안에 외부 코드나 로직의 주입을 막는다는 것이 헥사고날 아키텍처의 핵심이다.
위 그림을 바탕으로 흐름을 소개하면 다음과 같다. 전체적인 흐름은 왼쪽에서 오른쪽으로 처리 된다.
1. 왼쪽의 Adapter들을 통해 클라이언트의 요청을 받아 Application Service에 전달한다. 이때 Service와 Adapter는 Port를 이용해 인터페이스를 맞춘다
2. Application Service는 들어온 요청을 도메인 모델로 전달한다.
3. 도메인 모델은 전달받은 요청으로 비즈니스 모델을 처리하고, 우측에 있는 어댑터들을 통해 외부의 데이터를 가져오거나 처리된 데이터를 외부로 저장한다.
4. Application Service는 도메인 모델의 결과를 사용자에게 반환한다.
주요 컴포넌트
헥사고날 아키텍처를 구성하는 주요 컴포넌트는 다음과 같다.
- Adapters / Ports
- Application Services
- Domain Model
Adapter
어댑터는 포트를 통해 인프라와 실제로 연결하는 부분만 담당하는 구현체이다. 어댑터는 아래와 같이 두 가지로 나뉠 수 있다.
- 사용자의 요청을 받아들일때 사용하는 driving adapter(primary adapter)
- AWS Lambda의 Handler
- WebApplication의 Controller
- 도메인 모델의 처리에 사용되는 driven adapter(secondary adapter)
- MessageQueue, Persistence Adapter
어댑터 패턴에 대해 익숙하지 않다면 이 링크를 참조하면 된다.
Port
- 인터페이스 정의만 존재한다.
- DI(Dipendecy Inversion)을 위한 추상화이다.
Application Service(Usecase)
- 어댑터를 주입(Injection) 받아 도메인 모델과 어댑터를 적절히 오케스트레이션한다.
도메인 모델
- DDD의 도메인 모델
- 모든 엔티티에 대한 변경은 여기서만 실행한다.
- 이런 엔티티에 대한 변경을 일반적으로 비즈니스 로직이라고 부른다.
- 어떠한 의존성도 없어야 하는 것이 원칙
- 이지만 Entity를 만들 때 데이터베이스에 적재되어 있는 데이터를 참고해야하는 경우와 같은 상황에서는 Port를 이용해 Adapter를 주입받아 사용할 수 있다는 예외가 있다(클린 아키텍쳐와 동일)
왜 헥사고날 / 클린 아키텍처인가?
- 명확한 관심사의 분리
- 외부와의 연결에 문제가 생기면? -> 어댑터
- 인터페이스는? -> 포트
- 처리 중간에 EventBridge에 이벤트를 보내거나 트레이스 로그를 심고 싶다면? -> 서비스
- 비즈니스 로직이 제대로 동작하지 않으면? -> 도메인 모델
- 쉬운 테스트
- 자기 역할만 Port 기반 모킹을 통해 테스트
- 비즈니스 로직은 의존성이 없기 때문에 모킹(mocking)이 거의 없음
헥사고날 아키텍처의 예제는 GitHub 예제 를 참고하자.
