chore(wiki): reinforce knowledge batch #6-#10 (200 docs milestone)
This commit is contained in:
Antigravity Agent
@@ -1,30 +1,37 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-048
|
||||
id: DDD-MASTER-001
|
||||
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)."
|
||||
confidence_score: 1.0
|
||||
tags: [architecture, ddd, strategic-design, tactical-design, ubiquitous-language]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Domain-Driven Design (DDD)]] (도메인 주도 설계)
|
||||
# [[Domain-Driven Design (DDD, 도메인 주도 설계)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 소프트웨어의 복잡성을 관리하기 위해, 비즈니스 도메인의 핵심 개념(Ubiquitous Language)을 중심으로 시스템 경계(Bounded Context)를 설정하고 모델링하는 접근 방식이다.
|
||||
> "복잡한 비즈니스 로직을 소프트웨어의 심장으로 만들어라" — 기술적 복잡성보다 비즈니스 도메인의 복잡성을 우선시하며, 개발자와 전문가가 동일한 언어(Ubiquitous Language)로 소통하며 설계하는 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **핵심 목표:** 기술적 구현에 앞서 '도메인 전문가의 언어'가 소프트웨어의 설계 원칙이 되도록 강제함으로써, 개발자가 도메인의 본질을 놓치지 않게 하는 것이 목적이다.
|
||||
- **주요 개념:**
|
||||
1. **유비쿼터스 언어 (Ubiquitous Language):** 비즈니스 사용자와 개발자 모두가 같은 단어를 사용하며 오해의 소지를 없애는 공통 언어. 이는 코딩과 문서화에 일관되게 반영되어야 한다.
|
||||
2. **바운디드 컨텍스트 (Bounded Context, BC):** 하나의 개념(예: '사용자')이 시스템 내에서 다르게 정의될 수 있음을 인지하고, 각 비즈니스 영역별로 경계를 설정한다. (Context-Mapping).
|
||||
3. **애그리게이트 (Aggregate):** 트랜잭션의 일관성을 보장하는 데이터 단위. 애그리게이트 루트(Aggregate Root)를 통해 내부 객체들의 변경을 제어하며, 데이터베이스 레벨에서 무결성을 유지한다.
|
||||
- **추출된 패턴:** 거대한 시스템을 독립적인 의미를 가진 '바운디드 컨텍스트(Bounded Context)'로 나누고, 그 내부를 핵심 도메인 모델 중심으로 구축하는 아키텍처 패턴.
|
||||
- **전략적 설계 (Strategic Design):**
|
||||
- **Ubiquitous Language:** 개발자, 기획자, 도메인 전문가가 모두 사용하는 공통 언어 정의.
|
||||
- **Bounded Context:** 특정 모델이 적용되는 논리적인 경계 설정. 컨텍스트 간의 관계는 Context Map으로 정의.
|
||||
- **Core Domain:** 비즈니스의 가장 핵심적인 가치를 창출하는 영역에 자원 집중.
|
||||
- **전술적 설계 (Tactical Design):**
|
||||
- **Entity & Value Object:** 식별자 기반의 객체와 속성 기반의 값 객체 구분.
|
||||
- **Aggregate:** 데이터 변경의 단위로 묶인 객체들의 집합. Root 엔티티를 통해서만 접근.
|
||||
- **Repository:** 도메인 객체의 생명주기를 관리하고 저장소 추상화 제공.
|
||||
- **Domain Service:** 특정 엔티티에 속하기 어려운 비즈니스 로직 처리.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** DDD가 모든 문제에 대한 해결책은 아니며, 도메인이 명확하지 않은 초기 단계에서는 오히려 오버 엔지니어링(Over-engineering)을 초래할 수 있다. 우선적으로 가장 복잡하고 중요한 핵심 영역부터 적용하는 전략이 필요하다.
|
||||
- **정책 변화:** 마이크로서비스 아키텍처와 매우 높은 시너지를 내며, 각 서비스가 하나의 Bounded Context를 담당하도록 경계를 설정하는 것이 일반적이다.
|
||||
- **과거 데이터와의 충돌:** 과거의 데이터베이스 중심 설계(ERD 중심)에서 행위와 도메인 로직 중심의 설계로 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트는 '지식 관리', '게임 엔진', '데이터 수집'을 각각의 Bounded Context로 분리하고, 컨텍스트 간 통신은 메시지 큐를 통한 비동기 방식을 지향함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Parent: [[Microservices-Architecture]]
|
||||
- Related: [[Bounded Contexts]] , [[Ubiquitous Language]] , [[Aggregate Root]]
|
||||
- Raw Source: [[00_Raw/Domain-Driven Design (DDD).md]]
|
||||
---
|
||||
- **Parent:** [[10_Wiki/💡 Topics/Software Architecture]]
|
||||
- **Related:** [[Bounded-Context]], [[Microservices]], [[Clean-Architecture]], [[Event-Sourcing]]
|
||||
- **Merged Sources:**
|
||||
- [[10_Wiki/Topics/AI/Domain-Driven Design (DDD) in TypeScript.md]]
|
||||
- [[10_Wiki/Topics/AI/Domain-Driven Design (DDD) Type Safety.md]]
|
||||
- [[10_Wiki/Topics/AI/도메인 주도 설계 (Domain-Driven Design DDD).md]]
|
||||
- [[10_Wiki/Topics/Frontend_Mastery/Domain-Driven Design (DDD).md]]
|
||||
Reference in New Issue
Block a user