DDD(Domain Driven Design)

개요

DDD(Domain Driven Design, 도메인 주도 설계)는 복잡한 비즈니스 도메인을 효과적으로 반영하고 유지보수 가능한 소프트웨어를 개발하기 위한 모델 중심의 설계 철학입니다. Eric Evans가 제안한 이 개념은 도메인 전문가와 개발자 간의 협업을 중심에 두고, 공통된 언어(Ubiquitous Language), 도메인 모델링, 계층화 설계 등을 통해 소프트웨어와 비즈니스 간의 일관성을 확보합니다. 이 글에서는 DDD의 개념, 핵심 원칙, 구성 요소, 적용 전략 등을 체계적으로 설명합니다.

---

1. 개념 및 정의

DDD는 비즈니스 도메인 지식을 바탕으로 소프트웨어를 설계하고 구현하는 접근 방식입니다. 소프트웨어의 구조와 용어가 비즈니스의 본질을 반영하도록 하여, 개발자와 도메인 전문가가 동일한 모델과 언어로 커뮤니케이션할 수 있게 만드는 것이 핵심입니다.

DDD는 단순한 코드 구조 설계가 아닌, 비즈니스 복잡성을 효과적으로 캡슐화하고 모델링하는 아키텍처 전략입니다.

---

2. 특징

특징	설명	기대 효과
도메인 모델 중심	핵심 도메인을 중심으로 설계를 진행	비즈니스 로직과 코드의 일치성 확보
공통 언어(Ubiquitous Language)	개발자와 도메인 전문가가 공유하는 용어 체계	커뮤니케이션 오류 감소
계층화 아키텍처	도메인, 애플리케이션, 인프라, UI 레이어 분리	역할 명확화, 유지보수 용이성
바운디드 컨텍스트	도메인 간 명확한 경계 설정	시스템 분할 및 마이크로서비스와의 정합성
지속적 리팩토링	모델과 구현이 함께 진화	비즈니스 변화에 대한 유연한 대응

---

3. 주요 구성 요소

구성 요소	설명	예시
Entity	고유 식별자를 가지며 상태가 변화하는 도메인 객체	주문(Order), 사용자(User) 등
Value Object	값 자체로 비교되며 불변성을 가지는 객체	주소(Address), 좌표(Coordinate)
Aggregate	일관성을 유지해야 하는 도메인 객체의 집합체, 루트 엔티티로 관리됨	주문 → 주문 항목(루트: 주문)
Repository	Aggregate를 저장/조회하는 인터페이스	OrderRepository, UserRepository 등
Service	도메인 객체가 갖기 어려운 도메인 로직을 표현	결제 처리, 배송 추적 로직 등
Domain Event	도메인 상태 변화에 대한 명시적 이벤트	주문 생성됨(OrderCreated), 결제 완료됨 등

---

4. 기술 요소 및 설계 원칙

기술/설계 요소	설명
계층화 아키텍처	도메인 계층을 중심으로 UI, Application, Infrastructure 구분
바운디드 컨텍스트	컨텍스트마다 별도의 모델 정의, 컨텍스트 간 통합은 Context Mapping으로 해결
Event Storming	도메인 이벤트 중심의 모델링 기법
CQRS (Command Query Responsibility Segregation)	읽기/쓰기 책임 분리 구조로 복잡성 분산
Hexagonal Architecture	내부 도메인과 외부 시스템 간의 의존성을 포트와 어댑터로 격리

---

5. 장점 및 이점

장점	설명	적용 효과
비즈니스 연계 강화	모델이 도메인 로직과 일치하므로 의사결정 반영이 용이	전략적 의사결정 기반 시스템 구현
변경 용이성	도메인 모델의 유연성으로 인한 코드 구조의 적응성	비즈니스 변화 대응 능력 향상
마이크로서비스와 궁합 우수	바운디드 컨텍스트 개념이 서비스 경계와 잘 맞음	서비스 간 분리 및 독립 배포 구조 가능
개발자-전문가 협업 용이	공통 언어를 기반으로 명세 및 테스트 주도 설계 가능	요구사항 변경 시 혼선 최소화

---

6. 주요 활용 사례 및 고려사항

활용 사례

• 전자상거래 플랫폼: 상품, 주문, 결제, 배송 등 각 도메인별 모델을 분리해 설계
• 금융 시스템: 계좌, 이체, 인증 등 복잡한 업무 로직을 바운디드 컨텍스트로 분리
• ERP 시스템: 재무, 인사, 생산 도메인을 명확히 나누어 모델링
• 마이크로서비스 설계: 도메인 단위로 서비스 분할 시 바운디드 컨텍스트 기준 적용

고려사항

고려 항목	설명
초기 도입 학습 비용	도메인 모델링, 공통 언어 정의 등 초반 커뮤니케이션과 설계 역량 요구
과도한 분리 위험	바운디드 컨텍스트가 너무 세분화되면 오히려 복잡도 증가 가능성
유스케이스 중심 설계와 균형	도메인 중심과 서비스 중심 설계를 적절히 조화시켜야 실용적인 구조 도출 가능
구현 기술과의 정합성	ORM, API 설계, 이벤트 메시징 등과의 통합 기술 고려 필요

---

7. 결론

DDD는 소프트웨어를 단순히 '코드'가 아닌, 비즈니스 전략의 표현 수단으로 바라보는 강력한 설계 방법론입니다. 복잡한 업무 도메인을 이해하고, 이를 코드와 모델로 명확히 구현하고자 할 때, DDD는 개발팀과 비즈니스 팀 간의 협업을 극대화하고 시스템을 장기적으로 유연하게 유지할 수 있는 구조를 제공합니다. 변화가 빠르고 복잡성이 높은 현대 시스템에서는 DDD의 적용이 점점 더 필수 전략으로 자리 잡고 있습니다.