[아키텍처] 헥사고날 아키텍처

헥사고날 아키텍처

소프트웨어 설계에 사용되는 아키텍처 패턴 중 하나로 여러 소프트웨어 환경에 쉽게 연결할 수 있도록, 느슨하게 결합된 애플리케이션 구성 요소를 만드는 것을 목표로 하는 아키텍처

 

도메인 비즈니스 로직을 외부 라이브러리 및 툴로부터 분리할 때 포트와 어댑터라고 부르는 인터페이스를 사용하기 때문에,

포트와 어댑터 아키텍처라고도 부름

 

헥사고날 아키텍처의 핵심

도메인 비즈니스 로직의 외부 요소에 의존하지 않게 만들고, 프레젠테이션 계층(controller)과 데이터 소스 계층(persistence) 같은 외부 요소들이 도메인 계층에 의존하도록 함

-> 외부와의 접촉을 인터페이스로 추상화하여 비즈니스 로직 안에 외부 코드나 로직의 주입을 막는 것, 

외부 라이브러리 및 툴로부터 분리시키는 것이 아키텍처의 핵심

 

헥사고날 아키텍처의 구성

포트와 어댑터

개발을 시작할 때 포트와 어댑터의 역할,

두 어댑터 간의 차이점을 제대로 인지한다면, 개발이 수월함 (domain + application layer까지 비즈니스 로직임)

 

포트

Port는 application 입장에서 consumer, 또는 application에서 나가거나/들어오는 end point라고 볼 수 있음

 

어댑터

인프라나 web과 같은 저수준 layer들이 도메인 로직에 접근할 수 있는 포트를 사용할 수 있도록 함

 

Primary (Driving) Adapters

adapter, application을 동작시키는 (Driving) 역할을 함. Driving Adapter에는 주로 UI 쪽이 들어감. 인바운드 포트 사용

 

Secondary (Driven) Adapters

adapter, application에 의해 동작되는 역할을 가진 부분. 주로 인프라와 연결되는 부분이 들어감. 아웃바운드 포트 사용

primary adapter에 의해 Secondary adapter들이 호출됨. (인바운드 adapter, 아웃바운드 adapter라고 부르기도 함)

 

또한 두 종류의 adapter에서 어떻게 port와 adapter가 쓰이는지도 차이점이 있음

Primary adapter는 port에 의존하고 있음. 실제로 사용될 때는 구체적인 port의 구현체가 adapter에 주입됨

 

이때 port와 그 구현체는 application 내부에 속하게 됨

 

Secondary adapter는 port의 구현체가 되고, application의 비즈니스 로직에 주입됨. 그렇기 때문에 application 비즈니스 로직의 입장에서는 port의 interface만 알고 있음. 이때 port는 application 내부에 속하지만, port의 구체적인 구현체는 application 외부에 속하게 됨. 그리고 그 구현체는 외부 tool을 감싸고 있음

 

헥사고날 아키텍처 장점

1. 도메인 비즈니스 모델에 집중
   • DIP를 통해 의존성이 도메인에서 밖으로 나가는 부분이 없으므로 외부 요소를 신경쓰며 개발할 필요가 없음
2. 모듈 일부를 배포하는 게 용이
   • 기술과 실제 비즈니스 로직의 분리
   • 각 도메인 별 비즈니스 로직 분리를 통해 느슨한 결합을 가져가기 때문
3. 기능 확장이 용이
   • 원하는 기능에 대한 포트와 해당 포트를 사용할 어댑터를 추가해주면 됨
4. 쉬운 테스트 구성
   • 모든 외부 기술들은 포트를 통해 비즈니스 로직과 연결되기 때문에, 본인의 역할을 수행하기 위해 필요한 Port만 사용하여 모킹 어댑터를 통해 테스트를 쉽게 수행할 수 있음.
   • 내부 비즈니스 로직을 테스트할 때 외부에 의존성이 없기 때문에 모킹 필요성이 적어짐
5. 개발 비용 감소
   • 모든 의존성이 도메인을 향하기 때문에 계층간 의존성이 낮아지고, 유연해지기 때문에 요구사항에 빠르게 대처할 수 있고, 테스트도 쉽게 적용할 수 있음
6. SoC(관심사 분리)의 장점
   • 외부와의 연결에 문제가 생기면 Adapter를 확인하면 될 것이고, 인터페이스의 정의를 변경하고자 한다면 port를
   • 마지막으로 비즈니스 로직이 제대로 동작하기 않는다면 도메인 로직만 확인하면 되기 때문에 결국 쉬운 테스트를 가능하게 해주기도 함

헥사고날 아키텍처 단점

1. 코드가 많아짐
   • 도메인 계층이 영속성, UI 같은 외부 계층과 철저히 분리되어야 하기 때문에 엔티티에 대한 모델을 각 계층에서 유지보수해야 함
   • ORM 프레임워크는 DB구조 및 객체 필드와 컬럼의 매핑을 서술한 메타데이터를 담고 있는 엔티티 클래스를 필요로 함
   • 도메인 계층은 영속성 계층을 모르기 때문에, 두 계층에서 각각 엔티티를 만들어줘야하고 도메인 계층과 영속성 계층이 데이터를 주고 받을 때 두 엔티티를 서로 매핑하는 과정이 생기게 됨
   • 도메인 계층과 다른 계층 사이에서도 동일
2. 불필요한 오버헤드
   • 아키텍처를 도입하기 전 포트, 어댑터 등 알아야할 개념이 생기고
   • 아키텍처를 구현하기 위해서는 포트(인터페이스)를 생성해야 하고 도메인 모델의 여러 표현 사이를 매핑할 객체를 만들어야 함