2026-01-31 개발 : 레이어드 아키텍처와 DDD

개요

DDD와 레이어드 아키텍처로 코드를 작성한다고 했지만, 나는 흉내만 내었던 것 같다. 이번 글은 내가 헷갈렸던 지점을 정리하고 실무 코드에 적용할 수 있는 나만의 기준을 세워보려고 한다. 정리 과정에서 ChatGPT의 도움을 받았고, 내용에 오류가 있을 수 있기에 지속적으로 보완할 예정이다.

 

 

도메인

현실세계에 있는 문제를 소프트웨어로 해결하기 위한 관심사 또는 문제영역이다. 넓게는 금융 도메인, 커머스 도메인, 모빌리티 도메인, 광고 도메인 등. 여기서 좀 더 세분화해서 서브도메인으로 표현이 가능하다. 하지만 실제 대화를 하면 도메인이라는 것은 넓게, 좁게 문맥에 따라 다양하게 표현된다. 같은 단어라도 컨텍스트에 따라 의미가 달라진다.

• 금융 : 대출, 보험, 예적금 등
• 커머스 : 상품, 전시, 주문, 결제, 유통 등
• 모빌리티 : 버스, 지하철, 택시, 내비 등
• 광고 : 입찰, 과금, 타겟팅 등

 

도메인 로직

도메인이 가진 고유의 규칙과 논리 모음이다. 도메인 로직은 도메인 모델이 상태와 행위를 함께 가지며 행동할 수 있도록 설계하는 것이 목표다. 반면 유즈케이스를 수행하기 위한 흐름제어는 애플리케이션 게층의 오케스트레이션 책임으로 분리한다.

• 유즈케이스 오케스트레이션 : 애플리케이션 로직
• 도메인 규칙 : 도메인 로직

도메인 로직은 가능한 Aggregate 내부로 두고 스스로 규칙을 처리하도록 한다. 하지만 모델 내부에서 자연스럽게 들어가지 않는 로직들은 도메인 서비스로 분리할 수 있다.

 

 

애그리게이트 (Aggregate)

도메인 문제를 해결하기 위해서 일관성을 보장하기 위한 경계를 Aggregate 라고 한다. Repository를 통해서 Aggregate를 조회/저장한다. 외부에선 Aggregate Root를 통해서만 상태를 변경한다. 내부의 행위로 도메인 규칙을 수행하도록 설계한 방식을 Rich Domain Model이라고 한다. 반대로 도메인 로직이 모델 밖에 있고, 값만 담는 DTO처럼 되어있다면 그건 Anemic Domain Model에 가깝다.

 

 

레이어드 아키텍처와 DDD

레이어드 아키텍처에서는 의존성이 위에서 아래로 단방향으로 흐른다. 이 단방향 자체는 도메인이 인프라를 참조하도록 강제하는 것이 아니지만, 3 Layer 를 인프라나 프레임워크 중심으로 구현하다 보면 도메인 코드가 인프라에 결합되는 형태가 나올 수 있다.

 

DDD 관점에서는 도메인을 외부 기술로부터 보호하기 위해, 도메인 계층이 인프라 구현에 직접 의존하는 것을 지양한다. 도메인이 필요로 하는 의존 지점은 Port (인터페이스) 같은 추상화로 표현하고 실제 구현체는 인프라 계층에 두되, Port를 향하도록 한다. (DIP 원칙)

 

애플리케이션은 유즈케이스를 오케스트레이션 하면서, 포트를 통해서 필요한 애그리게이트를 조회/저장한다. 트랜잭션 경계와 락, 재시도와 보상 그리고 여러 애그리게이트의 조합 등 프로세스 제어를 담당한다. 반면 도메인 서비스와 도메인 모델은 불변조건(도메인 규칙)을 중심으로 구성하며 유즈케이스 오케스트레이션 책임을 갖지 않는다.

 

 

결론

DDD 는 문제 해결을 위해 무엇을 중심에 둘 것인지 설계하는 관점. 레이어드 아키텍처는 시스템 구조를 어떻게 나눌 것인지 결정하는 구조적 관점이다. 이 둘은 목적이 다르다. 도메인 모델을 중심에 두고 이를 외부로부터 보호해서 아키텍처를 구성할 때 두 목적은 서로 의미 있게 부합된다.

 

 

에릭에반스 DDD 내용을 보면 아래와 같은 내용있다.

도메인 규칙을 격리하는게 최종목표이며, 아키텍처는 그 목표를 실현시키기 위한 패턴 혹은 구조라고 생각한다.

 

Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.

The key goal here is isolation. Related patterns, such as “Hexagonal Architecture,” may serve as well or better to the degree that they allow our domain model expressions
to avoid dependencies on and references to other system concerns.

 

 

관련자료

• 에릭에반스, DDD
• 마틴파울러, 빈약한 도메인 모델
• 마틴파울러, 도메인 모델
• 알리스테어 콕크번, 헥사고날 아키텍처
• 로버트 마틴, 클린 아키텍처
• MS, DDD 마이크로서비스