[MSA] 헥사고날 아키텍처(Hexagonal Architecture)

들어가며

이번 글에서는 이벤트 스토밍 결과물을 실제로 구현할 수 있도록 표현하는 헥사고날 아키텍처에 대해 알아보도록 한다. 이벤트 스토밍이 생소하다면 다음의 글을 먼저 참고하기 바란다.

2022.02.15 - [MSA 설계 & 도메인 주도 설계] - [MSA] 이벤트 스토밍(Event storming)

[MSA] 이벤트 스토밍(Event storming)

---

헥사고날 아키텍처란?

 헥사고날 아키텍처는 소프트웨어 설계에 사용되는 아키텍처 패턴 중 하나다. 포트와 어댑터를 통해 여러 소프트웨어 환경에 쉽게 연결할 수 있도록, 느슨하게 결합된 응용 프로그램 구성요소를 만드는 것을 목표로 한다.

 이 아키텍처는 구성 요소를 모든 수준에서 쉽게 교환할 수 있게 하고 테스트 자동화를 용이하게 한다. 헥사고날 아키텍처에서 사용하는 포트(Port)와 어댑터(Adapter)의 이름을 따서 포트 앤드 어댑터 아키텍처(Ports and adapters architecture - 엘리스테어 콕번)라고도 불린다.

Hexagonal architecture

 

참고할 수 있는 이전글 :)

2022.01.17 - [MSA 설계 & 도메인 주도 설계] - [MSA] 레이어드 아키텍처 vs 헥사고날 아키텍처 vs 클린 아키텍처 요약

[MSA] 레이어드 아키텍처 vs 헥사고날 아키텍처 vs 클린 아키텍처 요약

 

---

필요성

헥사고날 아키텍처는 다음의 이슈사항들을 해결하기 위해 고안되었다.

• 테스트가 힘든점
  테스트해야 하는 로직들이 프론트엔드의 세부 변경사항들에 의존해야 하기 때문에 테스트가 힘들다.
• 연동이 힘든 점
  프로젝트 구현체가 다른 프로그램 혹은 서비스와 연동하기 힘들다.
• 자동화 테스트가 힘든점
  자동화 테스트 시스템을 이용하여 자동화 테스트를 진행하기 힘들다.
• 소프트웨어 품질 오염
  레이어 간의 원하지 않는 종속성 발생 및 비즈니스 로직으로 인한 사용자 인터페이스가 오염되어 문제가 발생한다.

---

구성

 헥사고날 아키텍처에서 사용되는 어댑터의 의미는 디자인 패턴 중 어댑터 패턴(Adapter pattern)과 의미가 같다. 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환하는 것처럼, 서비스 비즈니스 로직을 외부 영역의 필요성에 맞게 변환하는 것이다. 아래의 도식은 헥사고날 아키텍처의 전체적인 구성을 나타낸다.

 

헥사고날 아키텍처의 구성 (색상은 필자가 설명을 위해 부여한 것이다.)

헥사고날 아키텍처는 연동 부분과 비즈니스로직을 기준으로 외부 영역과 내부영역으로 나뉜다.

 

외부와의 통신 관점에서 바라볼 때는 인바운드 부분 (빨간색)과 아웃바운드 부분 (파란색)으로 나뉜다.

 

인바운드 부분은 인바운드 어댑터 (연한 빨간색)과 인바운드 포트 (진한 빨간색)으로 나뉜다.

 

아웃바운드 부분은 아웃바운드 어댑터 (연한 파란색)와 아웃바운드 포트 (진한 파란색)으로 나뉜다. 

 

 각 모듈의 의미는 다음과 같다.

 

• 인바운드 포트
  외부 영역이 내부 영역을 호출하는 방법 정의
• 아웃바운드 포트
  내부 영역이 외부 영역을 호출하는 방법 정의
• 인바운드 어댑터
  외부 시스템 또는 서비스가 서비스를 호출하기 위한 방법 정의 (예: REST API  컨트롤러, 도메인 이벤트 핸들러)
• 아웃바운드 어댑터
  서비스가 외부 시스템 또는 서비스를 호출하기 위한 방법 정의 (예: API 프락시 어댑터, 이벤트 메시지 퍼블리셔)
• 비즈니스 로직
  애그리거트가 중심이 된 도메인 업무 관련 로직

애플리케이션의 순수한 비즈니스 로직을 내부 영역에서 구현하고, 다른 서비스 또는 기타 요청에 대한 연동 및 비즈니스 로직의 세부 구현은 외부 영역에서 담당하는 것이 핵심이다.

---

이벤트 스토밍(Event stroming)과의 관계

 이벤트 스토밍을 통해 도출된 내용들을 토대로 헥사고날 아키텍처를 구성할 수 있다. 이벤트 스토밍을 진행하고 난 뒤 상세 설계 입력물을 얻을 수 있다.

사용자 서비스의 상세 설계 입력물 예시

 상세 설계 입력 물의 커맨드(Command), 도메인 이벤트(Domain event), 그리고 정책(Policy) 들이 식별되었을 때, 이를 헥사고날 아키텍처로 변환할 수 있다.

상세 설계 입력물 기반 헥사고날 아키텍처

 

커맨드(Command)와 도메인 이벤트(Domain event)는 각각 인바운드 어댑터와 아웃바운드 어댑터로 배치할 수 있다.

---

정책 옵션

 정책(Policy)은 서비스 간 연계 관점에서 따라 두 가지 방식으로 나뉜다.

 

오케스트레이션(Orchestration) 방식

 이벤트를 발생시키는 주체에서 모든 Policy를 가지는 방식이다. 이 형태는 서비스간 커플링이 높기 때문에 시스템의 블로킹 가능성을 높인다.

정책(Policy) 연계 방식 중 오케스트레이션 예시

코레오그래피(Choreography) 방식

 구현하는 주체에서 Policy를 자율적으로 실행하는 방식이다. 이 형태는 서비스 간 커플링이 없고, 이벤트를 수신하는 서비스의 추가 삭제가 자유롭다.

정책(Policy) 연계 방식 중 코레오그래피 예시

---

마치며

 이번 글에서는 헥사고날 아키텍처에 대해 알아보았다. 필자는 이벤트 스토밍의 결과물을 통해 서비스를 어떻게 분리하는 것이 좋을지에 대한 아이디어는 얻었지만, 구현 단계와 연결하기는 쉽지 않았다.

 헥사고날 아키텍처로 각각의 요소들을 배치하고 나면 구현을 어떻게 해야 할지, 서비스 간 어떤 식으로 연동을 하는 것이 좋을지 파악하는데 도움이 되었다.

(육각형의 우측 상단, 좌측 상단 등 각 영역에 무엇을 배치할 것인지 정해놓고 배치하니, 정리하기 수월했다.)

 

[1] 마이크로서비스 모델링 - 이벤트 스토밍 | 2020 | SK C&C 기술블로그 | 링크

마이크로서비스 모델링 ④ : 이벤트 스토밍을 통한 마이크로서비스 도출

 

[2] 도메인 주도 설계 철저 입문 | 2022 | 나루세 마사노부 | 링크

도메인 주도 설계 철저 입문 - 교보문고

 

[3] 도메인주도 설계로 시작하는 마이크로서비스 개발 | 2021 | 한정헌, 유해식, 최은정, 이주영 | 링크

도메인 주도 설계로 시작하는 마이크로서비스 개발 - 교보문고

 

[4] 이벤트 스토밍 | MSA School | 링크

msaschool - msaschool