reinforce:wikify - Batch 10: Domain-Driven Design & Strategic Design (5 artifacts)

10_Wiki/Topics_Arch/Domain_Driven_Design.md

@@ -4,11 +4,11 @@ title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
 category: "10_Wiki/🏗️ Topics_Arch"
 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: ["Architecture", "DDD", "Ubiquitous_Language", "Bounded_Context", "Software_Design"]
+tags: ["DDD", "Architecture", "Software_Design", "Business_Logic", "Strategic_Design"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
@@ -17,29 +17,33 @@ github_commit: ""
 # [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
 
 ## 1. 개요
-Domain-Driven Design(DDD)은 복잡한 비즈니스 로직을 소프트웨어의 중심에 두고, 기술 팀과 도메인 전문가 간의 협력을 통해 비즈니스 프로세스를 코드로 모델링하는 설계 접근 방식이다. '유비쿼터스 언어'와 '바운디드 컨텍스트'를 통해 시스템의 복잡성을 관리 가능한 수준으로 분해한다.
+Domain-Driven Design(DDD)은 소프트웨어가 실제 비즈니스 로직과 규칙을 정확히 반영하도록 핵심 비즈니스 도메인(판매, 물류, 금융 등)을 모델링하는 데 집중하는 설계 철학이다. 기술적 세부 사항보다는 비즈니스의 복잡성을 해결하는 데 초점을 맞추며, 도메인 전문가와 개발자 간의 긴밀한 협업을 전제로 한다.
 
-## 2. 전략적 설계 (Strategic Design)
-- **유비쿼터스 언어 (Ubiquitous Language)**: 개발자와 비즈니스 이해관계자가 공통으로 사용하는 공유 언어. 코드, 문서, 대화에 동일하게 적용됨.
-- **바운디드 컨텍스트 (Bounded Context)**: 특정 도메인 모델이 적용되는 논리적 경계. 각 컨텍스트는 독립적인 모델과 언어를 가짐.
-- **컨텍스트 매핑 (Context Mapping)**: 서로 다른 바운디드 컨텍스트 간의 관계와 통신 방식을 정의.
+## 2. 주요 개념 및 구성 요소
+- **전략적 설계 (Strategic Design)**:
+    - **보편적 언어 (Ubiquitous Language)**: 팀 전체가 공유하는 공통의 비즈니스 용어 체계.
+    - **제한된 컨텍스트 (Bounded Context)**: 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
+- **전술적 설계 (Tactical Design)**:
+    - **엔티티 (Entity)**: 고유한 식별자를 통해 정체성이 유지되는 객체.
+    - **값 객체 (Value Object)**: 속성값 자체로 정의되며 불변성을 가지는 객체.
+    - **애그리게이트 (Aggregate)**: 데이터 변경의 단위로 묶인 객체들의 집합.
+    - **리포지토리 (Repository)**: 애그리게이트의 영속성을 관리하는 인터페이스.
 
-## 3. 전술적 설계 (Tactical Design)
-- **Entities (엔티티)**: 고유한 식별자를 가지며 상태가 변할 수 있는 객체.
-- **Value Objects (값 객체)**: 고유 식별자 없이 속성 값만으로 정의되는 불변 객체.
-- **Aggregates (애그리거트)**: 데이터 일관성을 보장하기 위해 하나로 묶인 도메인 객체 군집. 애그리거트 루트를 통해서만 접근 가능.
-- **Repositories**: 애그리거트의 영속성을 관리하는 인터페이스.
+## 3. 실전 아키텍처 결합
+- **육각형 아키텍처와의 조화**: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
+- **기술적 격리**: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.
 
-## 4. 트레이드오프
-- **장점**: 비즈니스 로직의 명확한 가시성, 유지보수성 향상, 유연한 아키텍처 확장(Microservices로의 전환 용이).
-- **단점**: 설계 및 구현 복잡도 상승, 도메인 전문가와의 긴밀한 협업 비용 발생, 단순한 프로젝트에서는 오버헤드.
+## 4. 트레이드오프 및 주의사항
+- **장점**: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
+- **단점**: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
+- **테스트 전략**: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.
 
 ## 5. 지식 연결 (Related)
-- [[Clean_Architecture]]: 도메인 로직을 외부 인프라로부터 보호하는 아키텍처.
-- [[Microservices_Architecture]]: 바운디드 컨텍스트를 물리적으로 구현하는 일반적인 방식.
-- [[Event_Storming]]: 도메인 모델을 도출하기 위한 협업 워크샵 기법.
+- [[Bounded_Context]]: 도메인 모델의 경계를 설정하는 전략적 도구.
+- [[Ubiquitous_Language]]: 협업과 모델링의 기초가 되는 공통 언어.
+- [[Hexagonal_Architecture]]: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 엔터프라이즈 급 소프트웨어 설계의 근간이 되는 DDD의 핵심 원칙 정립.
+- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.