2nd/01_Archive/2026-04-20/Domain-Driven Design (DDD).md

id, category, confidence_score, tags, last_reinforced, github_commit

id	category	confidence_score	tags	last_reinforced	github_commit
P-REINFORCE-AI-048	10_Wiki/💡 Topics/Software Architecture	0.99	ddd bounded context domain modeling software architecture	2026-06-XX	[P-Reinforce] Processed 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
• Related: Bounded Contexts , 보편적 언어 (Ubiquitous Language) , Aggregate Root
• Raw Source: 00_Raw/Domain-Driven Design (DDD).md

---