# [[도메인 주도 설계 (Domain-Driven Design, DDD)|도메인 주도 설계 (Domain-Driven Design, DDD)]]

## 📌 Brief Summary
도메인 주도 설계(DDD)는 비즈니스 도메인에 대한 깊은 이해를 중심으로 소프트웨어 개발 프로세스를 구성하는 설계 접근 방식입니다 [1]. 기술 팀과 도메인 전문가 간의 긴밀한 협력을 바탕으로 현실 세계의 비즈니스 프로세스를 정확하게 반영하는 소프트웨어 모델을 생성하는 것을 목표로 합니다 [1]. 이를 통해 시스템의 복잡성을 해결하고 개발자와 비즈니스 이해관계자 간의 의사소통 격차를 해소하여, 결과적으로 소프트웨어가 올바른 문제를 해결할 수 있도록 보장합니다 [1].

## 📖 Core Content
- **유비쿼터스 언어(Ubiquitous Language)의 확립:**
  DDD의 핵심 목표 중 하나는 프로젝트에 참여하는 모든 사람(개발자 및 도메인 전문가 등)이 공유하는 공통 어휘 사전인 '유비쿼터스 언어'를 만드는 것입니다 [1, 2]. 이 언어는 일상적인 대화, 문서화는 물론 실제 코드 자체에서도 동일하게 사용되어야 하며, 이를 통해 요구사항에 대한 오해를 방지하고 도메인 모델을 명확히 합니다 [1, 2].
- **제한된 컨텍스트(Bounded Contexts)를 통한 복잡성 관리:**
  크고 복잡한 도메인은 '주문 관리'나 '고객 지원'과 같이 더 작고 관리하기 쉬운 하위 도메인인 '제한된 컨텍스트'로 분할됩니다 [3]. 각 컨텍스트는 고유한 모델과 유비쿼터스 언어를 유지하여 모델의 순수성을 보장하고, 각기 다른 책임 영역 간의 명확한 경계를 정의하여 도메인 로직을 캡슐화합니다 [3-5].
- **전략적 모델링 구성 요소:**
  - **애그리게잇(Aggregates):** 단일 단위로 취급할 수 있는 도메인 객체들의 클러스터입니다(예: `OrderLineItem` 객체를 포함하는 `Order`). 애그리게잇의 루트는 전체 클러스터의 일관성을 보장하며 트랜잭션 관리를 단순화하는 역할을 합니다 [3].
  - **엔티티(Entities)와 값 객체(Value Objects):** 고유한 정체성(Identity)을 바탕으로 구별되는 객체(예: `Customer` 엔티티)와, 고유 식별자 없이 오직 속성으로만 정의되는 객체(예: `ShippingAddress` 값 객체)를 명확히 구분하여 설계합니다 [3].
- **도메인 로직의 격리 및 이벤트 스토밍(Event Storming):**
  핵심 비즈니스 로직은 데이터베이스나 UI 프레임워크와 같은 외부 인프라스트럭처 문제와 철저히 분리되어야 하며, 이를 통해 깔끔하고 테스트 및 유지보수가 쉬운 도메인 모델을 생성할 수 있습니다 [2]. 또한 비즈니스 도메인을 빠르게 탐색하고 도메인 이벤트, 명령, 애그리게잇을 식별하기 위해 '이벤트 스토밍(Event Storming)'과 같은 협업 워크샵을 적극적으로 활용하는 것이 권장됩니다 [2].
- **도입 시 특징 및 적합한 환경:**
  DDD는 깊은 도메인 모델링과 이해관계자의 지속적인 협업이 필수적이므로 초기 구현 복잡도와 리소스 요구 사항(분석 시간, 도메인 전문가 참여 등)이 상대적으로 높은 편입니다 [6]. 따라서 단순한 시스템보다는 금융, 의료, 이커머스와 같이 비즈니스 도메인이 매우 복잡한 엔터프라이즈 시스템 구축에 가장 이상적인 아키텍처 베스트 프랙티스입니다 [6].

## 🔗 Knowledge Connections
- **Related Topics:** [[유비쿼터스 언어 (Ubiquitous Language)|유비쿼터스 언어(Ubiquitous Language)]], 제한된 컨텍스트(Bounded Contexts), 애그리게잇(Aggregates), [[관심사의 분리(Separation of Concerns)|관심사의 분리(Separation of Concerns)]]
- **Projects/Contexts:** 복잡한 비즈니스 도메인(금융, 의료, 이커머스 등)을 다루는 대규모 시스템 개발 프로젝트
- **Contradictions/Notes:** 소스 내에서 상충하는 주장은 발견되지 않으나, DDD는 비즈니스 구조와의 강력한 일치와 명확한 도메인 모델을 제공하는 큰 장점이 있는 반면, 도입 시 도메인 전문가와의 심도 있는 협업 모델링이 필요하여 중간에서 높음(Medium-High) 수준의 복잡성과 리소스가 요구된다는 점이 주의사항으로 지적됩니다 [6].

---
*Last updated: 2026-04-18*