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

10_Wiki/Topics_Arch/Bounded_Context.md

@@ -0,0 +1,44 @@
+---
+id: P-REINFORCE-WIKI-ARCH-BOUNDED-CONTEXT
+title: "제한된 컨텍스트 (Bounded Context)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["바운디드 컨텍스트", "Bounded Context", "도메인 경계", "모듈 분할"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DDD", "Architecture", "Strategic_Design", "Microservices", "Modularity"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[제한된 컨텍스트 (Bounded Context)]]
+
+## 1. 개요
+Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)의 전략적 설계(Strategic Design)에서 가장 핵심적인 개념으로, 특정 모델과 용어(Ubiquitous Language)가 온전하게 의미를 유지하며 적용되는 논리적인 경계를 의미한다. 대규모 시스템을 관리 가능한 독립적인 단위로 분해하고, 팀 간의 명확한 책임 경계를 긋는 나침반 역할을 한다.
+
+## 2. 핵심 원리
+- **언어의 일관성**: 같은 '사용자(User)'라는 용어라도 결제 컨텍스트와 배송 컨텍스트에서는 서로 다른 속성과 행위를 가질 수 있다. Bounded Context는 이러한 언어의 다의성을 인정하고 경계 내에서의 일관성을 보장한다.
+- **명확한 경계 (Explicit Boundary)**: 각 컨텍스트는 고유한 코드베이스, 데이터베이스, 팀 소유권을 가질 수 있으며, 외부 컨텍스트와의 통신은 정의된 인터페이스를 통해서만 이루어진다.
+- **독립적 진화**: 경계가 명확히 분리되어 있으므로, 한 컨텍스트의 기술 스택 변경이나 내부 로직 리팩토링이 전체 시스템에 미치는 파급 효과를 최소화한다.
+
+## 3. 실전 적용 및 가치
+- **마이크로서비스의 기준**: Bounded Context는 마이크로서비스 아키텍처에서 개별 서비스의 경계를 정의하는 가장 신뢰할 수 있는 기준이 된다.
+- **코드베이스 탐색**: 비즈니스 용어 중심으로 폴더와 모듈이 구성되므로, 개발자는 기술적 레이어(Controller, Service 등)가 아닌 비즈니스 도메인(Order, Inventory 등)을 따라 코드를 해독할 수 있다.
+- **협업 최적화**: 팀별로 바운디드 컨텍스트를 할당함으로써 의사소통 비용을 줄이고 자율성을 부여한다.
+
+## 4. 트레이드오프 및 주의사항
+- **설계 복잡도**: 도메인에 대한 심층적인 분석이 선행되어야 하며, 경계를 잘못 설정할 경우 컨텍스트 간의 중복 데이터 관리나 통신 복잡성이 증가한다.
+- **컨텍스트 매핑 (Context Mapping)**: 분리된 컨텍스트들이 서로 데이터를 주고받기 위해서는 공유 커널(Shared Kernel)이나 안티 코럽션 레이어(ACL) 같은 명시적인 관계 정의가 필수적이다.
+
+## 5. 지식 연결 (Related)
+- [[Domain_Driven_Design]]: Bounded Context를 포함하는 상위 설계 철학.
+- [[Ubiquitous_Language]]: 컨텍스트 내부에서 사용하는 통용 언어.
+- [[Microservices_Architecture]]: Bounded Context가 물리적으로 구현된 아키텍처 스타일.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 대규모 시스템의 복잡성을 통제하고 독립적인 모듈화 성숙도를 높이기 위한 전략적 설계 표준 정립.

10_Wiki/Topics_Arch/DDD_Aggregates.md

@@ -0,0 +1,44 @@
+---
+id: P-REINFORCE-WIKI-ARCH-DDD-AGGREGATES
+title: "애그리거트 패턴과 데이터 일관성 (DDD Aggregates)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["애그리거트", "Aggregate", "애그리거트 루트", "일관성 경계"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DDD", "Architecture", "Consistency", "Transaction", "Tactical_Design"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[애그리거트 패턴과 데이터 일관성 (DDD Aggregates)]]
+
+## 1. 개요
+애그리거트(Aggregate)는 도메인 주도 설계(DDD)의 전술적 설계(Tactical Design) 패턴 중 하나로, 데이터 변경의 단위로 취급될 수 있는 연관된 도메인 객체(엔티티와 값 객체)의 클러스터를 의미한다. 애그리거트는 내부 객체들 간의 비즈니스 규칙(Invariants)을 유지하고 트랜잭션의 일관성 경계를 정의하는 역할을 한다.
+
+## 2. 핵심 구성 및 원칙
+- **애그리거트 루트 (Aggregate Root)**: 외부에서 애그리거트 내부로 접근할 수 있는 유일한 관문. 모든 상태 변경은 루트를 통해서만 이루어지며, 루트는 전체 클러스터의 일관성을 책임진다.
+- **일관성 경계**: 하나의 트랜잭션 내에서는 하나의 애그리거트만 수정되는 것을 권장한다. 다른 애그리거트의 상태 변경은 도메인 이벤트를 통한 결과적 일관성(Eventual Consistency)으로 처리한다.
+- **객체 캡슐화**: 루트가 아닌 내부 엔티티는 외부에서 직접 참조하거나 수정할 수 없으며, 루트를 통한 간접 호출만 허용된다.
+
+## 3. 실전 적용 가치
+- **트랜잭션 단순화**: 복잡한 비즈니스 로직에서도 일관성이 유지되어야 하는 데이터 범위를 명확히 획정함으로써 데이터 오염 방지.
+- **도메인 모델의 응집도 향상**: 논리적으로 밀접하게 연관된 객체들을 하나로 묶어 비즈니스 개념을 명확하게 표현.
+- **성능 및 확장성**: 애그리거트 단위를 작게 유지함으로써 트랜잭션 충돌을 최소화하고 분산 시스템(마이크로서비스)으로의 전환 용이성 확보.
+
+## 4. 트레이드오프 및 주의사항
+- **설계 난이도**: 비즈니스 규칙을 완벽히 이해해야 적절한 애그리거트 경계를 설정할 수 있음. 너무 크면 성능 저하와 락(Lock) 경합이 발생하고, 너무 작으면 일관성 유지가 어려움.
+- **식별성 관리**: 애그리거트 간의 참조는 식별자(ID)를 통해서만 이루어져야 하며, 메모리상의 직접 참조는 지양해야 함.
+
+## 5. 지식 연결 (Related)
+- [[Domain_Driven_Design]]: 애그리거트가 속한 상위 설계 방법론.
+- [[Event_Storming]]: 애그리거트를 도출하기 위한 실천적 워크샵.
+- [[Bounded_Context]]: 애그리거트가 존재하고 유효성을 가지는 논리적 공간.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 데이터 무결성과 트랜잭션 일관성을 보장하는 전술적 설계의 핵심 패턴 정립.

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의 핵심 원칙 정립.
+- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.

10_Wiki/Topics_Arch/Event_Storming.md

@@ -0,0 +1,47 @@
+---
+id: P-REINFORCE-WIKI-ARCH-EVENT-STORMING
+title: "이벤트 스토밍 기반의 도메인 탐색 (Event Storming)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["이벤트 스토밍", "Event Storming", "도메인 탐색 워크샵", "비즈니스 모델링"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DDD", "Collaboration", "Strategic_Design", "Event_Storming", "Modeling"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[이벤트 스토밍 기반의 도메인 탐색 (Event Storming)]]
+
+## 1. 개요
+이벤트 스토밍(Event Storming)은 비즈니스 도메인을 깊이 탐색하고 복잡한 시스템의 구조를 식별하기 위한 협업 워크샵 기법이다. 개발자, 아키텍트, 도메인 전문가가 함께 참여하여 서비스의 흐름을 시각화하고, 도메인 이벤트(Domain Events), 명령(Commands), 애그리거트(Aggregates) 등 핵심 설계 요소를 신속하게 도출하는 데 최적화되어 있다.
+
+## 2. 워크샵 구성 요소
+- **도메인 이벤트 (Orange Card)**: 비즈니스에서 발생한 과거 시점의 중요한 사건. 시스템의 상태 변화를 나타냄.
+- **명령 (Blue Card)**: 사용자의 의도나 시스템에 의해 발생하는 동작. 이벤트를 트리거함.
+- **애그리거트 (Yellow Card)**: 명령을 받아 이벤트를 생성하는 데이터와 로직의 군집(트랜잭션의 단위).
+- **액터/사용자 (Small Yellow)**: 명령을 수행하는 주체.
+- **정책 (Lilac Card)**: 이벤트가 발생했을 때 자동으로 실행되는 반응 로직.
+
+## 3. 실전 적용 가치
+- **비즈니스-기술 싱크로**: 도메인 전문가의 지식을 개발자가 즉각적으로 이해하고 모델링에 반영 가능.
+- **병목 지점 식별**: 전체 프로세스를 시각화하는 과정에서 비즈니스상의 비효율이나 병목 지점을 자연스럽게 발견.
+- **아키텍처 설계의 뼈대**: 도출된 이벤트와 애그리거트는 바운디드 컨텍스트를 정의하고 마이크로서비스 경계를 나누는 결정적 근거가 됨.
+
+## 4. 트레이드오프 및 주의사항
+- **장점**: 짧은 시간 내에 복잡한 도메인에 대한 공통 멘탈 모델 형성.
+- **단점**: 도메인 전문가의 적극적인 참여 없이는 반쪽짜리 결과가 나올 수 있으며, 대규모 인원이 참여할 경우 퍼실리테이션 역량이 중요함.
+- **주의**: 시각화된 결과물에만 집중하지 말고, 그 과정에서 오가는 '대화'와 '보편적 언어'의 확립을 최우선으로 할 것.
+
+## 5. 지식 연결 (Related)
+- [[Domain_Driven_Design]]: 이벤트 스토밍을 통해 구현하고자 하는 설계 철학.
+- [[DDD_Aggregates]]: 이벤트 스토밍에서 도출된 핵심 데이터 관리 단위.
+- [[Event_Driven_Architecture]]: 도메인 이벤트를 물리적으로 구현하는 아키텍처 스타일.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 도메인 모델링과 시스템 설계를 위한 실천적인 협업 프레임워크 표준 정립.

10_Wiki/Topics_Arch/Ubiquitous_Language.md

@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-ARCH-UBIQUITOUS-LANGUAGE
+title: "보편적 언어 (Ubiquitous Language)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["보편적 언어", "Ubiquitous Language", "공통 언어", "도메인 용어집"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DDD", "Communication", "Modeling", "Strategic_Design", "Collaboration"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[보편적 언어 (Ubiquitous Language)]]
+
+## 1. 개요
+보편적 언어(Ubiquitous Language)는 도메인 주도 설계(DDD)에서 개발자, 도메인 전문가, 이해관계자 등 프로젝트 팀 전체가 모델을 정의하고 소통할 때 사용하는 공통된 언어 체계이다. 기술적 용어가 아닌 비즈니스 도메인의 개념을 반영하며, 대화뿐만 아니라 소스 코드, 문서, 다이어그램에 일관되게 적용되어 의사소통의 간극을 해소한다.
+
+## 2. 핵심 가치
+- **의사소통 비용 절감**: 모호한 기술 용어나 잘못 해석된 비즈니스 용어로 인한 오해를 방지하여 설계의 정확도 향상.
+- **코드와 모델의 일치**: 보편적 언어로 정의된 개념이 클래스명, 변수명, 메서드명에 직접 반영되어 코드가 곧 비즈니스 문서의 역할을 수행.
+- **의미적 경계 형성**: 특정 용어가 바운디드 컨텍스트(Bounded Context) 내에서만 유효한 의미를 가짐으로써 모듈 간의 결합도를 낮추고 응집도를 높임.
+
+## 3. 구축 및 실천 방법
+- **용어집 관리**: 도메인 전문가와 협의하여 핵심 도메인 개념에 대한 명확한 정의와 용어를 정리한 공유 용어집(Shared Glossary) 유지.
+- **이벤트 스토밍 (Event Storming)**: 협업 워크샵을 통해 도메인 이벤트와 커맨드를 식별하며 자연스럽게 보편적 언어 도출.
+- **지속적 갱신**: 비즈니스 환경이 변화함에 따라 도메인 모델과 언어를 끊임없이 동기화하고 코드에 반영.
+
+## 4. 트레이드오프 및 주의사항
+- **협업 오버헤드**: 도메인 전문가의 지속적인 참여와 깊은 모델링 시간이 필수적이므로 초기 분석 리소스가 많이 소요됨.
+- **엄격한 규율 요구**: 팀 내에서 약속된 용어를 코드에 강제하고, 일관성을 유지하기 위한 지속적인 리뷰와 문서화 노력이 필요함.
+- **컨텍스트 오염 방지**: 하나의 단어가 여러 컨텍스트에서 서로 다른 의미로 쓰일 경우, 이를 명확히 분리된 바운디드 컨텍스트로 격리하여 언어의 순수성 유지.
+
+## 5. 지식 연결 (Related)
+- [[Domain_Driven_Design]]: 보편적 언어를 활용하는 상위 설계 철학.
+- [[Bounded_Context]]: 보편적 언어의 유효 범위를 설정하는 경계.
+- [[Event_Storming]]: 보편적 언어를 효율적으로 도출하기 위한 협업 기법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 비즈니스 요구사항을 코드에 정확히 투영하고 팀의 인지적 동기화를 이루기 위한 가장 근본적인 소통 표준 정립.