DDD(Domain Driven Development)

1. 프로세스와 무관한 패턴과 원칙의 집합, DDD 개요

1) DDD의 정의

DDD(Domain Driven Development)는 소프트웨어의 핵심 복잡성(Core Complexity)을 해결하기 위해 도메인 모델을 중심(Model-Driven Design)으로 설계·구현하는 소프트웨어 개발 접근법이다.

이 개념은 Eric Evans가 저서 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 체계화하였다.

정의 요약

• 비즈니스 도메인을 중심으로 모델을 설계
• 모델과 코드의 정합성을 유지
• 개발자와 도메인 전문가 간 공통 언어(UBIQUITOUS LANGUAGE) 사용
• 프로세스 자체가 아니라 패턴·원칙·Best Practice 집합

 

2) DDD의 필요성

구분	전통적 개발 방식 문제	DDD 접근
복잡성 관리	비즈니스 규칙이 분산됨	도메인 모델에 응집
요구사항 변화	변경 시 영향 범위 불명확	Aggregate 단위 변경
개발-현업 간 소통	문서 중심, 해석 차이 발생	UBIQUITOUS LANGUAGE 사용
코드 구조	CRUD 중심 설계	도메인 행위 중심 설계

DDD는 특히 다음과 같은 환경에서 효과적이다:

• MSA 기반 복잡한 업무 시스템
• 비즈니스 규칙이 많은 금융/물류/ERP 시스템
• 장기 유지보수 프로젝트

 

2. DDD 구조도와 기본요소 및 특징

1) DDD Layered 구조도

DDD Layer Stack

계층 설명

Layer	책임	특징
Presentation	UI/API	외부 인터페이스
Application	유스케이스 orchestration	트랜잭션 제어
Domain	핵심 비즈니스 로직	Entity, Value, Aggregate
Infrastructure	DB, MQ, 외부시스템	기술 구현

핵심은 Domain Layer가 독립적이어야 한다는 점이다.

 

2) 도메인 모델(Domain Model)

도메인 모델은 다음을 포함한다:

• Domain 객체
• 비즈니스 규칙
• 제약조건
• 상태 및 행위

MODEL DRIVEN DESIGN의 핵심은

모델 = 설계 = 코드 의 일치성을 유지하는 것이다.

 

3) DDD 기본 요소 및 특징

구분	설명
UBIQUITOUS LANGUAGE	도메인 전문가와 개발자가 공유하는 공통 언어
Bounded Context	모델의 경계를 명확히 정의
Aggregate	트랜잭션 일관성 경계
Repository	Aggregate 저장소
Domain Service	Entity로 표현하기 어려운 로직
Entity	식별자 기반 객체
Value Object	불변 객체
Domain Event	상태 변화 이벤트

4) DDD 특징

• 도메인 중심 설계
• 객체지향 설계 원칙 강화
• 응집도 ↑ 결합도 ↓
• 복잡성의 구조화
• 전략적 설계(Strategic Design) + 전술적 설계(Tactical Design)

 

5) 효과적인 모델링 구성요소

• Bounded Context 명확화
• Context Mapping
• Aggregate 단위 설계
• 명확한 UBIQUITOUS LANGUAGE 정의
• 도메인 전문가 참여

 

3. DDD의 기본 구성 요소 (Tactical Pattern)

도메인 모델 기본 구성 요소 통합표

요소	정의	특징	예시
Entity	식별자를 가지는 객체	상태 변화 가능	Order
Value Object	값 자체가 의미	불변(Immutable)	Money
Aggregate	객체 묶음 단위	일관성 경계	Order + OrderLine
Repository	Aggregate 저장	인터페이스 중심	OrderRepository
Domain Service	특정 Entity에 속하지 않는 로직	Stateless	PaymentService
Factory	복잡한 생성 책임	생성 로직 캡슐화	OrderFactory
Domain Event	도메인 변화 표현	비동기 처리 가능	OrderCreated

주요 요소 상세

Entity	Value Object	Aggregate	Repository	Service
고유 ID 존재 동일성(Identity) 기반 비교 생명주기 관리	불변 객체 값 비교 부작용 최소화	Root(Entity) 중심 구성 외부는 Root만 참조 가능 트랜잭션 단위	Domain ↔ Persistence 분리 인터페이스는 Domain에 위치	특정 Entity에 귀속 불가한 로직 도메인 규칙 표현

 

4. DDD 적용 전제사항과 Process

1) DDD 전제사항

항목	설명
복잡한 도메인 존재	단순 CRUD 시스템은 불필요
도메인 전문가 협업 가능	UBIQUITOUS LANGUAGE 필요
장기 운영 시스템	단기 프로젝트에는 부적합
객체지향 이해도 확보	설계 역량 요구

2) DDD Process

1. 도메인 탐색 (Domain Exploration)
2. UBIQUITOUS LANGUAGE 정의
3. Bounded Context 식별
4. Aggregate 설계
5. Repository 설계
6. Domain Service 정의
7. Infrastructure 연결

 

5. DDD 모델 구조와 계층 구조

1) 모델 구조

2) 계층 구조 통합 설명

구분	전략적 설계	전술적 설계
목적	도메인 경계 설정	모델 구현
구성	Bounded Context, Context Map	Entity, Value, Aggregate
관심사	시스템 전체 구조	객체 내부 구조

6. DDD 적용 시 고려사항

1) 도메인 로직 복잡성과 코드 재사용

• 복잡성 낮은 시스템 → 과도한 설계 위험
• Generic Framework 과용 지양
• 도메인 중심 응집 설계 유지

MSA 환경에서는 서비스 단위 = Bounded Context로 설계하는 것이 적합

 

2) 도메인 로직과 유지보수 관계

항목	DDD 미적용	DDD 적용
변경 영향	광범위	Aggregate 단위
테스트	통합 테스트 중심	도메인 단위 테스트 가능
확장성	기술 중심	비즈니스 중심

결론

DDD는 단순한 설계 기법이 아니라:

• 복잡성 관리 전략
• 도메인 중심 개발 철학
• 모델 기반 설계(MODEL DRIVEN DESIGN)
• UBIQUITOUS LANGUAGE 기반 협업 체계

특히 MSA, Spring 기반 대규모 업무 시스템 환경에서는 Bounded Context를 서비스 단위로 정립하고 Aggregate 중심 설계를 적용하는 것이 매우 효과적이다.

 

참고 문헌

1. Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
2. Implementing Domain-Driven Design – Vaughn Vernon
3. Domain-Driven Design Distilled – Vaughn Vernon