Refactor: Consolidate directory structure into 5 main categories and update metadata

10_Wiki/Topics_Dev/Domain_Driven_Design.md

@@ -1,52 +1,49 @@
 ---
-id: P-REINFORCE-WIKI-DEV-DDD
-title: "도메인 주도 설계와 비즈니스 중심 아키텍처 (DDD)"
-category: "10_Wiki/💻 Topics_Dev"
+id: P-REINFORCE-WIKI-ARCH-DDD
+title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
+category: Dev
 status: verified
 canonical_id: ""
-aliases: ["DDD", "도메인 주도 설계", "Domain-Driven Design", "전략적 설계", "전술적 설계"]
+aliases: ["DDD", "Domain-Driven Design", "도메인 주도 개발", "전략적 설계"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["DDD", "Architecture", "Software_Design", "Modeling", "Complexity_Management"]
+tags: ["DDD", "Architecture", "Software_Design", "Business_Logic", "Strategic_Design"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---
 
-# [[도메인 주도 설계와 비즈니스 중심 아키텍처 (DDD)]]
+# [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
 
 ## 1. 개요
-도메인 주도 설계(DDD, Domain-Driven Design)는 소프트웨어의 복잡성을 해결하기 위해 비즈니스 도메인(핵심 비즈니스 규칙과 실세계의 비즈니스 프로세스)을 아키텍처와 설계의 중심에 두는 접근 방식이다. 기술적 세부사항보다는 비즈니스의 본질을 모델링하고, 개발팀과 도메인 전문가가 동일한 언어로 소통하며 시스템을 구축함으로써 요구사항의 오해를 줄이고 소프트웨어의 가치를 극대화하는 것을 목표로 한다.
+Domain-Driven Design(DDD)은 소프트웨어가 실제 비즈니스 로직과 규칙을 정확히 반영하도록 핵심 비즈니스 도메인(판매, 물류, 금융 등)을 모델링하는 데 집중하는 설계 철학이다. 기술적 세부 사항보다는 비즈니스의 복잡성을 해결하는 데 초점을 맞추며, 도메인 전문가와 개발자 간의 긴밀한 협업을 전제로 한다.
 
-## 2. 핵심 체계 (Strategic & Tactical)
-- **전략적 설계 (Strategic Design)**: 시스템의 거시적인 구조를 결정하는 단계.
-  - **Bounded Context**: 모델이 유효한 논리적 경계 설정.
-  - **Ubiquitous Language**: 팀 전체가 공유하는 공통 언어 정의.
-  - **Context Mapping**: 컨텍스트 간의 관계와 데이터 흐름 정의.
-- **전술적 설계 (Tactical Design)**: 도메인 모델을 코드로 구현하는 구체적인 패턴.
-  - **Aggregates**: 데이터 무결성을 보장하는 객체들의 군집.
-  - **Entities & Value Objects**: 식별성 유무에 따른 객체 분류.
-  - **Repositories & Services**: 데이터 영속성 처리 및 도메인 로직 오케스트레이션.
-  - **Domain Events**: 시스템 상태 변화를 알리는 비동기 신호.
+## 2. 주요 개념 및 구성 요소
+- **전략적 설계 (Strategic Design)**:
+    - **보편적 언어 (Ubiquitous Language)**: 팀 전체가 공유하는 공통의 비즈니스 용어 체계.
+    - **제한된 컨텍스트 (Bounded Context)**: 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
+- **전술적 설계 (Tactical Design)**:
+    - **엔티티 (Entity)**: 고유한 식별자를 통해 정체성이 유지되는 객체.
+    - **값 객체 (Value Object)**: 속성값 자체로 정의되며 불변성을 가지는 객체.
+    - **애그리게이트 (Aggregate)**: 데이터 변경의 단위로 묶인 객체들의 집합.
+    - **리포지토리 (Repository)**: 애그리게이트의 영속성을 관리하는 인터페이스.
 
-## 3. 엔지니어링 가치
-- **비즈니스 정렬성**: 소프트웨어 구조가 실제 비즈니스 프로세스와 일치하므로, 비즈니스의 변화가 시스템의 변경으로 정확하고 신속하게 전이됨.
-- **복잡성 제어**: 거대한 모놀리식 시스템을 명확한 경계(Bounded Context)를 가진 독립적인 모듈들로 분해하여 인지 부하를 줄이고 관리 효율성을 높임.
-- **테스트 및 유지보수 용이성**: 핵심 도메인 로직이 인프라스트럭처나 UI와 격리되어 있어, 핵심 비즈니스 규칙에 대한 정밀한 테스트와 안전한 리팩토링이 가능.
+## 3. 실전 아키텍처 결합
+- **육각형 아키텍처와의 조화**: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
+- **기술적 격리**: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.
 
 ## 4. 트레이드오프 및 주의사항
-- **높은 초기 학습 곡선**: DDD의 방대한 용어와 철학을 이해하고 숙련되는 데 많은 시간과 노력이 필요함.
-- **도메인 전문가의 참여 필수**: 기술진만으로는 DDD를 성공시킬 수 없으며, 비즈니스 지식을 가진 전문가의 적극적이고 지속적인 참여가 필수적임.
-- **오버엔지니어링 경계**: 비즈니스 로직이 단순한 경우에는 오히려 과도한 추상화와 계층 분리로 인해 개발 속도만 늦출 수 있으므로, 도메인의 복잡도에 따른 선별적 도입이 중요함.
+- **장점**: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
+- **단점**: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
+- **테스트 전략**: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.
 
 ## 5. 지식 연결 (Related)
-- [[Bounded_Context]]: DDD의 전략적 설계의 핵심 요소.
-- [[Ubiquitous_Language]]: DDD 팀이 소통하는 기반 언어.
-- [[Aggregates]]: DDD의 전술적 설계의 핵심 요소.
-- [[Clean_Architecture]]: DDD와 결합하여 도메인을 보호하는 강력한 아키텍처 스타일.
+- [[Bounded_Context]]: 도메인 모델의 경계를 설정하는 전략적 도구.
+- [[Ubiquitous_Language]]: 협업과 모델링의 기초가 되는 공통 언어.
+- [[Hexagonal_Architecture]]: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 소프트웨어의 가치를 결정하는 핵심 비즈니스 로직을 중심으로 지속 가능하고 확장성 있는 시스템을 구축하기 위한 글로벌 설계 표준 정립.
+- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.