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

설명

‣ 포트 앤 어댑터 아키텍처을 이용
‣ 외부영역 & 내부영역 을 나눠 고수준의 내부 영역이 외부 영역에 의존하지 않도록 하는것이다!
‣ 유지보수, 유연성, 확장성에 좋음.
‣ 복잡할수록 빛을 발하지만, 단순하다면 경우 이렇게까지 구성할 필요는 없음!

🔸 외부영역
• 비지니스 처리 결과 리턴 (REST API 발행)
• 인바운드 어댑터, 아웃바운드 어댑터로 구성

🔸 내부영역
• 순수 비지니스 로직 구성
• 외부영역과 연계되는 포트를 가지고 있음
• 인바운드 포트, 아웃바운드 포트로 구성
• POJO 존재

‣ 아웃바운드 어댑터가 아웃바운드 포트에 의존해서 구현됨
‣ 어플리케이션이나 어댑터가 변경 되어도 도메인은 영향을 받지않음
‣ 클린 아키텍처와도 유사
‣ SOLID의 단일책임원칙(Single Reason to Change Principle, SRP), 의존성역전원칙(Dependency Inversion Principle, DIP) 을 이용

※ 포트 앤 어댑터 아키텍처
인터페이스나 기반 요소의 변경에 영향을 받지 않는 핵심 코드를 만들고 이를 견고하게 관리하는것이 목표
외부영역과 내부영역을 분리함
영역의 사이 input, ouput 전달은 포트(=인터페이스) 을 통해서만 함.

※ 단일책임원칙(Single Reason to Change Principle, SRP)
하나의 컴포넌트는 오로지 한 가지 일만 해야하고, 그것을 올바르게 수행해야함! 
= 컴포넌트 변경 이유는 오직 하나뿐이여야함!!!

※ 의존성역전원칙(Dependency Inversion Principle, DIP) 
코드상의 어떤 의존성이든 그 방향을 바꿀 수 있다.

 

구조

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

 

https://github.com/wikibook/clean-architecture

🌱 인바운드 포트
▪︎ 인바운드 어댑터가 호출(사용함)

🌱 아웃바운드 포트
▪︎ 아웃바운드 어댑터가 아웃바운드 포트에 의존하여 구현
(=아웃바운드 포트가 아웃바운드 어댑터 구현체 호출)

🌱 인바운드 어댑터
▪︎ 외부요청 처리 (API 요청/응답 결과)
▪︎ 아웃바운드 포트 인터페이스를 가져다가 사용하여 어댑터를 생성.
▪︎ 스프링 MVC 컨트롤러, 커맨드 핸들러, 이벤트 메세지 구독 핸들러 등.

🌱 아웃바운드 어댑터
▪︎ 내부 비지니스 영역과 외부 서비스간 데이터 교환
▪︎ 데이터 엑세스 처리 (DAO), 이벤트 메세지 발생, 외부 서비스 호출 등 

 

 

이를 사용하계된 계기 (계층형 아키텍처의 단점)

‣ 계층형 아키텍처는 데이터베이스 주도 설계를 유도함. (도메인에 의존이 아닌 데이터베이스에 의존) - 비지니스 관점으로는 별로임
‣ ORM 프레임워크의 경우 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받음.
‣ 영속성 코드가 도메인코드에 녹아들면 마음대로 바꾸기가 쉽지 않게 됨.
‣ 웹 계층 테스트시 도메인 및 영속성 범위까지 모킹해야함. 시간소요가 많아짐.
‣ 그외에도 테스트가 어렵고 동시작업이 어려움.
‣ 유지보수 쉬운! 소프트웨어를 만들필요성이 있다.

 

 

 

 

---

참고

- 링크: https://engineering.linecorp.com/ko/blog/port-and-adapter-architecture/

- 링크: https://velog.io/@youngmin-mo/hexagonalarchitecture

- 인프런강의: https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

- 책: 만들면서 배우는 클린 아키텍처