---
id: P-REINFORCE-AI-048
category: "10_Wiki/💡 Topics/Software Architecture"
confidence_score: 0.99
tags: [ddd, bounded context, domain modeling, software architecture]
last_reinforced: 2026-06-XX
github_commit: "[P-Reinforce] Processed Domain-Driven Design (DDD)."
---

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

## 📌 한 줄 통찰 (The Karpathy Summary)
> 소프트웨어의 복잡성을 관리하기 위해, 비즈니스 도메인의 핵심 개념(Ubiquitous Language)을 중심으로 시스템 경계(Bounded Context)를 설정하고 모델링하는 접근 방식이다.

## 📖 구조화된 지식 (Synthesized Content)
- **핵심 목표:** 기술적 구현에 앞서 '도메인 전문가의 언어'가 소프트웨어의 설계 원칙이 되도록 강제함으로써, 개발자가 도메인의 본질을 놓치지 않게 하는 것이 목적이다.
- **주요 개념:**
    1. **유비쿼터스 언어 (Ubiquitous Language):** 비즈니스 사용자와 개발자 모두가 같은 단어를 사용하며 오해의 소지를 없애는 공통 언어. 이는 코딩과 문서화에 일관되게 반영되어야 한다.
    2. **바운디드 컨텍스트 (Bounded Context, BC):** 하나의 개념(예: '사용자')이 시스템 내에서 다르게 정의될 수 있음을 인지하고, 각 비즈니스 영역별로 경계를 설정한다. (Context-Mapping).
    3. **애그리게이트 (Aggregate):** 트랜잭션의 일관성을 보장하는 데이터 단위. 애그리게이트 루트(Aggregate Root)를 통해 내부 객체들의 변경을 제어하며, 데이터베이스 레벨에서 무결성을 유지한다.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** DDD가 모든 문제에 대한 해결책은 아니며, 도메인이 명확하지 않은 초기 단계에서는 오히려 오버 엔지니어링(Over-engineering)을 초래할 수 있다. 우선적으로 가장 복잡하고 중요한 핵심 영역부터 적용하는 전략이 필요하다.
- **정책 변화:** 마이크로서비스 아키텍처와 매우 높은 시너지를 내며, 각 서비스가 하나의 Bounded Context를 담당하도록 경계를 설정하는 것이 일반적이다.

## 🔗 지식 연결 (Graph)
- Parent: [[Microservices-Architecture|Microservices-Architecture]]
- Related: [[Bounded Contexts|Bounded Contexts]] , [[보편적 언어 (Ubiquitous Language)|Ubiquitous Language]] , Aggregate Root
- Raw Source: 00_Raw/Domain-Driven Design (DDD).md
---