Hexagonal Architecture

Layered Architecture를 썼더라도 실제 코드에서는 ORM 엔티티가 도메인 모델을 대신하고, 컨트롤러에서 쓰던 DTO가 규칙 판단까지 끌고 들어오는 일이 자주 생깁니다. 이 상태에서는 프레임워크를 바꾸거나 저장소 방식을 교체할 때 핵심 로직까지 같이 흔들립니다. 테스트도 DB와 메시지 브로커 없이는 핵심 규칙을 검증하기 어렵습니다. 구조상 도메인 코어를 보호하는 장치가 약하면 기술 선택이 곧바로 모델을 침식합니다.

웹 프레임워크와 ORMs가 보편화되면서 생산성은 높아졌지만, 그만큼 애플리케이션 코어가 기술 구현 세부사항에 묶이기 쉬워졌습니다. 특히 오래 가는 비즈니스 규칙을 가진 시스템에서는 저장 기술과 전송 기술이 바뀌어도 모델은 오래 남아야 했습니다. 이 압력 속에서 의존성 방향을 바꾸고, 코어를 바깥 기술로부터 고립시키는 구조가 널리 쓰이기 시작했습니다.

바깥에서 들어오는 요청은 REST 어댑터, 메시지 소비자, CLI 같은 입력 어댑터가 받아서 입력 포트로 변환합니다. 코어는 입력 포트를 통해 유스케이스를 실행하고, 저장이나 외부 호출이 필요하면 출력 포트를 사용합니다. 실제 DB 저장, 메시지 발행, 외부 API 호출은 출력 포트의 구현체인 어댑터가 담당합니다. 이 덕분에 테스트에서는 어댑터 대신 가짜 구현을 꽂아 핵심 규칙만 검증할 수 있습니다.

Layered Architecture가 책임을 위아래로 나누는 구조라면, Hexagonal Architecture는 의존성 방향을 안쪽으로 고정하는 구조입니다. DDD가 어떤 모델을 코어에 둘지 정하는 관점이라면, Hexagonal은 그 코어를 어떻게 보호할지 정하는 관점입니다. 단순 CRUD 앱처럼 도메인 규칙이 얕고 기술 교체 가능성도 낮은 시스템이라면 이 구조를 지나치게 엄격하게 적용하는 비용이 더 클 수 있습니다.

도메인 규칙은 오래가는데 외부 기술은 바뀔 가능성이 높거나, 테스트에서 핵심 로직을 빠르게 검증해야 하거나, 하나의 코어를 여러 입력 채널과 출력 채널에 연결해야 하는 시스템에 잘 맞습니다. 특히 Modular Monolith나 Microservices 내부에서 도메인 코어를 지키는 구조로 자주 쓰입니다. 중요한 것은 포트가 너무 추상적이어서 아무 의미 없는 인터페이스 모음이 되지 않게, 실제 유스케이스를 반영하는 계약으로 유지하는 것입니다.