0. 문제
Domain-driven Design(DDD)에 관하여 설명하시오.
1. 서론
▣ 개념 정의
**DDD(Domain-driven Design, 도메인 주도 설계)**는 소프트웨어를 비즈니스 도메인 중심으로 설계하고, 개발자와 도메인 전문가가 **공통 언어(Ubiquitous Language)**를 기반으로 복잡한 문제를 효과적으로 해결하기 위한 설계 철학 및 방법론이다.
▣ 역사적 배경
- 2003년, Eric Evans가 저서 『Domain-Driven Design』에서 제안
- 복잡한 비즈니스 로직이 도메인과 무관한 기술 요소에 파묻히는 것을 방지하기 위해 등장
▣ 출현 목적
- 도메인 복잡도를 정확히 반영하고 소프트웨어에 일관되게 구현
- 개발자와 비즈니스 전문가 간 소통 강화
- 시스템의 유지보수성과 확장성 확보
2. 본론
▣ DDD의 핵심 개념 및 구조
| 개념 | 설명 |
|---|
| 도메인(Domain) | 해결하고자 하는 문제 영역(예: 은행, 물류, 쇼핑몰 등) |
| 유비쿼터스 언어(Ubiquitous Language) | 도메인 전문가와 개발자가 공유하는 공통 언어 |
| 엔티티(Entity) | 식별 가능한 고유 객체 (ex: 사용자, 주문 등) |
| 밸류 오브젝트(Value Object) | 속성만으로 정의되는 객체 (ex: 주소, 화폐 등) |
| 어그리거트(Aggregate) | 일관성을 보장하는 객체 집합의 루트 (Aggregate Root) |
| 도메인 서비스(Domain Service) | 엔티티에 속하지 않는 도메인 로직 담당 |
| 레포지토리(Repository) | 객체 저장소와의 추상화된 인터페이스 |
| 팩토리(Factory) | 복잡한 객체 생성을 캡슐화 |
📌 계층 구조
[ 사용자 인터페이스 ]
↓
[ 응용 계층 (Application Layer) ]
↓
[ 도메인 계층 (Domain Layer) ]
↓
[ 인프라 계층 (Infrastructure Layer) ]
▣ DDD의 적용 방식
| 절차 | 설명 |
|---|
| 도메인 분석 | 비즈니스 전문가와 협업하여 도메인 모델링 |
| 하위 도메인 분리 | Core, Supporting, Generic으로 구분 |
| 바운디드 컨텍스트(Bounded Context) 정의 | 명확한 책임과 경계를 설정 |
| 모델 구현 | 엔티티, 밸류 오브젝트, 도메인 서비스 등 구현 |
| 통합 | 컨텍스트 간 통합 방식 결정 (REST, 메시지 등) |
▣ 장단점
| 구분 | 장점 | 단점 |
|---|
| 설계 | 복잡한 도메인 정확히 반영 | 초기 설계 비용/노력 요구 |
| 개발 | 도메인 중심 설계로 유지보수 용이 | 학습 곡선 존재 |
| 협업 | 개발자와 도메인 전문가 간 협력 강화 | 조직 내 협업 구조 필수 |
| 테스트 | 도메인 단위 테스트 용이 | 구현 범위가 커질 수 있음 |
▣ 타 접근법과 비교
| 항목 | 전통적 설계 (CRUD 중심) | DDD |
|---|
| 중심 개념 | 데이터 구조 | 도메인 모델 및 규칙 |
| 구현 방식 | 테이블 중심 개발 | 객체 중심 모델링 |
| 복잡도 처리 | 코드 내 혼재 | 도메인 계층에 집중 |
| 변경 대응 | 영향도 높음 | 컨텍스트 내 국한 가능 |
▣ 실무 적용 전략
| 전략 | 설명 |
|---|
| 점진적 도입 | 핵심 도메인(Core Domain)부터 부분 적용 |
| Team Topology 연계 | 팀을 바운디드 컨텍스트 단위로 구성 (Stream-aligned 팀) |
| MSA 연계 | 각 Bounded Context를 독립 마이크로서비스로 구현 가능 |
| 모델 탐색 워크숍 | Event Storming, Domain Modeling 워크숍 등 활용 |
| TDD 기반 설계 | 테스트 주도 개발과 연계하여 도메인 로직 견고화 |
▣ 최신 트렌드 및 확장
| 트렌드 | 설명 |
|---|
| Event Storming | 도메인 이벤트 중심의 모델링 기법 |
| Hexagonal Architecture | 도메인 계층을 중심으로 포트-어댑터 구조 설계 |
| Event-Driven DDD | 도메인 이벤트를 기반으로 MSA 통합 구현 |
| Strategic DDD + Team Topologies | 조직 구조와 아키텍처를 동시 설계 |
3. 결론
▣ 어린이 버전 요약
DDD는 소프트웨어를 만들 때 현실 세계의 개념을 잘 표현해서, 사람들이 말하는 방식 그대로 프로그램을 짜는 방법이에요.
▣ 한눈에 보는 요약표
| 항목 | 설명 |
|---|
| 정의 | 도메인 중심의 설계 철학 및 방법론 |
| 핵심 개념 | Entity, Value Object, Aggregate, Bounded Context 등 |
| 계층 구조 | UI → Application → Domain → Infrastructure |
| 장점 | 복잡도 관리, 협업 강화, 유지보수 용이 |
| 단점 | 초기 비용, 학습 곡선, 조직적 합의 필요 |
| 실무 적용 | 핵심 도메인부터 점진적 도입 + 팀 구조 정비 |
| 최신 트렌드 | Event Storming, Hexagonal Architecture, MSA 연계 |
