| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- @ComponentScan
- @Transactional
- JPQL
- Spring
- redis
- DI
- JPA
- Routing Key
- kafka
- docker compose
- DLQ
- 서블릿 컨테이너
- Web
- 쿠버네티스
- Spring Data JPA
- 지연 로딩
- dockerhub
- securitycontextholderfilter
- 스프링 부트
- MSA
- Dead Letter Queue
- JdbcTemplate
- CORS
- JWT
- 페이징
- 컨테이너
- docker
- AWS
- Spring Container
- mybatis
- Today
- Total
look-forest
헥사고날 아키텍처 본문
아키텍처
시스템의 기본적인 구조를 정의한다.
계층형 아키텍처(Layered Architecture)
- 서브 시스템을 계층으로 구조화하는 아키텍처 스타일.
계층은 사용 관계로 연결된다. 단방향이어야 한다는 핵심 제약. 하향식 흐름. - 각 계층이 하위 계층의 내부 작동 방식을 알지 못하고, 제한된 인터페이스만 사용하도록 한다. (계층 격리 Layers of Isolation)
상위 계층에 노출할때는 제한된 인터페이스를 사용한다. - 어떤 레이어의 변경이 다른 레이어의 컴포넌트에게 가능한 영향을 주지 않도록 해야 한다.
3계층 아키텍처
UI(Presentation) → Domain(Business Logic) → Data(Persistence, Infra)

4계층 아키텍처
Presentation → Application Service → Domain → Infra

Layered Architecture를 쓰더라도, 기본적으로 계층 간은 인터페이스로 구분해야한다.
그래야 결합력이 약해져서 쉽게 구현체를 갈아끼울 수도 있고, 단위 테스트 시에도 mock bean을 넣을 수가 있다.
(서비스 구현체를 변경해야할 때, 기존 서비스 구현체를 복제해서 수정한 후에 @Service만 붙이면 된다)
헥사고날 아키텍처(Hexagonal Architecture)
- 애플리케이션의 내부와 외부 세계라는 대칭 구조를 가지는 대칭형 아키텍처
- 헥사곤의 내부: 쉽게 변하지 않는, 중요한 도메인 로직을 담은 코어 애플리케이션
- 도메인 로직을 가진 트랜잭션 스크립트
- 애플리케이션 서비스와 도메인 모델 패턴을 따라서 만든 도메인
- 헥사곤의 외부: 헥사곤과 상호작용하는 모든 것(Actor)
- 사용자, 브라우저, 메일 시스템, DB, 원격 서비스, 테스트 등
- 포트(Port): 애플리케이션 내부와 외부 액터 간의 상호작용 지점
- 헥사고날 아키텍처의 핵심은 의존성 역전. (추상에 의존) 포트도 애플리케이션 코어에 속한다.
- 어댑터(Adapter): 외부 액터가 애플리케이션 코어의 포트와 통신할 수 있도록 특정 기술에 맞춘 포트 인터페이스 구현체

헥사고날 아키텍처의 특징과 혜택
- 테스트를 쉽고 잘할 수 있도록.
- 운영 시스템에 연결되지 않고, 테스트 가능
- 상호작용하는 액터가 바뀌더라도 다시 빌드하지 않고 테스트
- 현대 코드는, 테스트 케이스를 줄이기 위한 방향으로 리팩토링하도록 진화했다. 역할이 줄어야 한다.
- 순수한 도메인.
- UI 디테일이나 기술 정보가 도메인 로직 안으로 노출되지 않도록 보호. 반대도 마찬가지
- 컴포넌트를 각각 개발하고 연결하는 방식으로 큰 시스템을 분리할 수 있다.
- 외부 연결을 다른 것으로 변경할 수 있다.
▷ 기술 요소를 제거했기 때문에 도메인 설계에 집중할 수 있다.
헥사고날 아키텍처가 제안된 주된 이유.
핵심 도메인 로직을 외부 기술로부터 분리하여, UI나 DB 등 외부 환경 변화와 무관하게 애플리케이션 코어를 쉽게 테스트하고 필요에 따라 교체할 수 있도록 하는 것이 중요한 목표이다.
헥사곤을 부르는 여러가지 이름
- 헥사곤
- (코어) 애플리케이션
- 앱(App)
- 코어 시스템
액터와 애플리케이션의 상호작용
포트(Port)를 이용
애플리케이션이 정의한 인터페이스로 만들어진다.
인터페이스의 종류
Lollipop: Provided Interface(기능 제공 인터페이스)
Socket: Required Interface(기능 요구 인터페이스)
어댑터(Adapter)
애플리케이션의 포트를 액터가 직접 연결할 수 없다면 인터페이스 변환을 위한 어댑터를 도입
- 브라우저를 통해 애플리케이션의 회원 가입 포트 기능 제공 인터페이스를 사용하려면,
→ 회원가입 기능 제공 인터페이스를 사용하는 웹 컨트롤러 어댑터를 만든다. - 애플리케이션이 가진 회원 정보 저장 포트의 기능 요구 인터페이스로 DB와 직접 연결할 수 없다면,
→ 기능 요구 인터페이스를 구현한 리포지토리 어댑터를 만든다.
포트와 어댑터 아키텍처: 헥사고날 아키텍처의 특징을 담은 새로운 이름
헥사고날 아키텍처의 비대칭성
- 애플리케이션이 제공하는 기능을 사용하는 액터와 이를 위한 어댑터
→ primary actor, primary adapter / driving actor, driving adapter - 애플리케이션이 동작하는 필요한 기능을 제공하는 액터와 이를 위한 어댑터
→ secondary actor, secondary adapter / driven actor, driven adapter
헥사고날 아키텍처의 사실과 오해
오해: 애플리케이션 내부에 도메인 계층을 만들어야 한다.
헥사고날 아키텍처는 애플리케이션 내부 구현에 대한 원칙이나 요구사항이 없다.
트랜잭션 스크립트를 써도 된다. 심지어 스파게티 코드도 된다.
도메인 계층을 포함하는 아키텍처는 클린 아키텍처이다.
오해: 헥사고날 아키텍처 패키지 구조를 따라야 한다.
헥사고날 아키텍처가 요구하는 패키지 구조는 없다.
애플리케이션과 어댑터 패키지를 분리하는 것은 바람직하다.
포트를 구분된 패키지에 두는 것을 권장한다.
오해: 포트는 UseCase라는 접미사를 사용한다.
길면서 특별한 의미를 주지 않아서 비호.
포트의 의도를 담은 이름을 사용하면 된다.
For ~ing 스타일의 권장 네이밍이 있지만 따를 필요는 없다.
오해: 애플리케이션은 도메인 모델만 넣고 JPA 엔티티 등은 어댑터에 둬야 한다.
애플리케이 코드와 포트 인터페이스가 외부 기술에 의존하지 않으면 된다.
사실: 헥사고날 아키텍처가 요구하는 것
- 애플리케이션은 모두 외부와의 상호작용을 위해서 provided interface와 required interface를 정의한다.
- 애플리케이션과 상호작용 하는 액터는 런타임에 구성되어야 한다.
- 애플리케이션은 액터에 대한 코드 의존성을 가지면 안 된다.
- 액터는 정의된 포트를 통해서만 연결해야 한다.
- 포트의 인터페이스에는 기술 의존성을 가지지 않는다.
헥사고날과 도메인 모델 패턴을 적용한 대칭형 계층 구조
- 도메인 계층
- 애플리케이션 계층 (포트까지 애플리케이션에 속함)
- 어댑터 계층
- 외부에서 내부로 향하는 일종의 계층 구조
- 코드의 의존 방향은 내부로만 향한다.
어댑터 → 애플리케이션 → 도메인
어댑터는 애플리케이션과 도메인의 영향을 받을 수 있으나, 반대는 안된다.
단, 사용의 흐름은 비대칭적이다.
도메인 주도 개발(DDD)의 아키텍처는?
4계층 아키텍처도 가능하지만, 헥사고날 아키텍처가 더 적합하다.
패키지구조
하나의 패키지에 여러 레이어가 있으면 안된다.
의존관계의 방향성이 잘못 되었을 때 파악하기가 쉽지 않기 때문.
## 패키지
- domain
- application
- required
- provided
- adapter
- webapi
- persistence
- integration
- security
참고 자료 & 이미지 출처
토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처
'Architecture > 도메인 모델과 헥사고날 아키텍처(Clean Spring)' 카테고리의 다른 글
| 웹 API 어댑터 개발 (작성중) (0) | 2025.09.08 |
|---|---|
| 애그리거트를 이용한 일관성 있는 도메인 모델 설계(작성중) (0) | 2025.09.06 |
| JPA와 도메인 모델 패턴 (작성 중) (0) | 2025.09.04 |
| 도메인 모델 (0) | 2025.09.02 |