---
id: P-REINFORCE-WIKI-ARCH-DDD
title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
category: "10_Wiki/🏗️ Topics_Arch"
status: verified
canonical_id: ""
aliases: ["DDD", "Domain-Driven Design", "바운디드 컨텍스트"]
duplicate_of: ""
source_trust_level: A
confidence_score: 1.0
tags: ["Architecture", "DDD", "Ubiquitous_Language", "Bounded_Context", "Software_Design"]
raw_sources: ["Datacollector_Export_2026-05-02"]
last_reinforced: 2026-05-02
github_commit: ""
---

# [[도메인 주도 설계 (Domain-Driven Design, DDD)]]

## 1. 개요
Domain-Driven Design(DDD)은 복잡한 비즈니스 로직을 소프트웨어의 중심에 두고, 기술 팀과 도메인 전문가 간의 협력을 통해 비즈니스 프로세스를 코드로 모델링하는 설계 접근 방식이다. '유비쿼터스 언어'와 '바운디드 컨텍스트'를 통해 시스템의 복잡성을 관리 가능한 수준으로 분해한다.

## 2. 전략적 설계 (Strategic Design)
- **유비쿼터스 언어 (Ubiquitous Language)**: 개발자와 비즈니스 이해관계자가 공통으로 사용하는 공유 언어. 코드, 문서, 대화에 동일하게 적용됨.
- **바운디드 컨텍스트 (Bounded Context)**: 특정 도메인 모델이 적용되는 논리적 경계. 각 컨텍스트는 독립적인 모델과 언어를 가짐.
- **컨텍스트 매핑 (Context Mapping)**: 서로 다른 바운디드 컨텍스트 간의 관계와 통신 방식을 정의.

## 3. 전술적 설계 (Tactical Design)
- **Entities (엔티티)**: 고유한 식별자를 가지며 상태가 변할 수 있는 객체.
- **Value Objects (값 객체)**: 고유 식별자 없이 속성 값만으로 정의되는 불변 객체.
- **Aggregates (애그리거트)**: 데이터 일관성을 보장하기 위해 하나로 묶인 도메인 객체 군집. 애그리거트 루트를 통해서만 접근 가능.
- **Repositories**: 애그리거트의 영속성을 관리하는 인터페이스.

## 4. 트레이드오프
- **장점**: 비즈니스 로직의 명확한 가시성, 유지보수성 향상, 유연한 아키텍처 확장(Microservices로의 전환 용이).
- **단점**: 설계 및 구현 복잡도 상승, 도메인 전문가와의 긴밀한 협업 비용 발생, 단순한 프로젝트에서는 오버헤드.

## 5. 지식 연결 (Related)
- [[Clean_Architecture]]: 도메인 로직을 외부 인프라로부터 보호하는 아키텍처.
- [[Microservices_Architecture]]: 바운디드 컨텍스트를 물리적으로 구현하는 일반적인 방식.
- [[Event_Storming]]: 도메인 모델을 도출하기 위한 협업 워크샵 기법.

## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 엔터프라이즈 급 소프트웨어 설계의 근간이 되는 DDD의 핵심 원칙 정립.
