2nd/10_Wiki/Topics_Arch/Domain_Driven_Design.md

---
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: ["DDD", "Architecture", "Software_Design", "Business_Logic", "Strategic_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)**: 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
- **전술적 설계 (Tactical Design)**:
    - **엔티티 (Entity)**: 고유한 식별자를 통해 정체성이 유지되는 객체.
    - **값 객체 (Value Object)**: 속성값 자체로 정의되며 불변성을 가지는 객체.
    - **애그리게이트 (Aggregate)**: 데이터 변경의 단위로 묶인 객체들의 집합.
    - **리포지토리 (Repository)**: 애그리게이트의 영속성을 관리하는 인터페이스.

## 3. 실전 아키텍처 결합
- **육각형 아키텍처와의 조화**: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
- **기술적 격리**: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.

## 4. 트레이드오프 및 주의사항
- **장점**: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
- **단점**: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
- **테스트 전략**: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.

## 5. 지식 연결 (Related)
- [[Bounded_Context]]: 도메인 모델의 경계를 설정하는 전략적 도구.
- [[Ubiquitous_Language]]: 협업과 모델링의 기초가 되는 공통 언어.
- [[Hexagonal_Architecture]]: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.

## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.