[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -1,88 +1,272 @@
 ---
 id: wiki-2026-0508-bounded-contexts
-title: Bounded Contexts
+title: Bounded Contexts (DDD)
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: [P-Reinforce-AI-BOUNDED-CONTEXT]
+aliases: [bounded context, BC, ubiquitous language, context mapping, domain-driven design, ACL, anti-corruption layer]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 0.99
-tags: [DDD, Bounded Context, Software Architecture, Domain]
+confidence_score: 0.93
+verification_status: applied
+tags: [ddd, bounded-context, ubiquitous-language, context-map, microservices, anti-corruption-layer, domain-modeling]
 raw_sources: []
-last_reinforced: 2026-04-20
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
 tech_stack:
-  language: unspecified
-  framework: unspecified
+  language: language-agnostic
+  framework: DDD / Clean Architecture
 ---

-# Bounded-Contexts (제한된 맥락)
+# Bounded Contexts

-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "모두를 위한 언어는 아무도 위한 언어가 아니다." 특정 도메인 내에서만 유효한 '의미의 경계'를 설정하여 복잡한 시스템을 명료하게 관리하는 DDD의 핵심 기법이다.
+## 📌 한 줄 통찰
+> **"매 모두 의 language = 매 아무도 의 language"**. 매 specific domain 의 internal 의 의미 boundary. 매 같은 word ('Account' = bank 의 계좌 vs login 의 ID) 의 isolation. 매 DDD 의 핵심. 매 microservice boundary 의 base.

-## 📖 구조화된 지식 (Synthesized Content)
- **Linguistic Boundary (언어적 경계)**:
-    - 'Account'라는 단어가 '은행' 맥락에서는 계좌이지만, '로그인' 맥락에서는 유저 ID일 수 있다. 이 두 의미가 섞이지 않도록 코드와 모델의 영역을 물리적으로 나누는 것이 핵심이다.
- **Ubiquitous Language (보편적 언어)**:
-    - 특정 바운디드 컨텍스트 안에서는 개발자나 기획자나 똑같은 단어를 똑같은 의미로 사용해야 한다.
- **Context Mapping**:
-    - 서로 다른 컨텍스트들이 어떻게 데이터를 주고받는지(Shared Kernel, Anti-Corruption Layer 등)의 관계도를 그리는 작업.
+## 📖 핵심

-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- 바운디드 컨텍스트를 너무 잘게 쪼개면 마이크로서비스(MSA)의 관리 복잡성(Distributed[[_system|system]] complexity)이 폭발한다. 처음에는 '모놀리식'으로 시작하되, 도메인 경계가 명확해지는 시점에 분리하는 전략이 실용적이다.
+### 매 정의 (Eric Evans)
+- 매 model 의 explicit boundary.
+- 매 ubiquitous language 의 작동 region.
+- 매 team / responsibility 의 align.

-## 🔗 지식 연결 (Graph)
- Related: [[Domain-Driven Design (DDD)|Domain-Driven Design (DDD)]] , [[Bounded-Contexts-and-Interface-Segregation|Bounded-Contexts-and-Interface-Segregation]]
- Foundation: [[Clean-Architecture-Implementation|Clean-Architecture-Implementation]]
+### 매 typical example
+| Context | "Customer" 의 의미 |
+|---|---|
+| Sales | 매 prospect / lead |
+| Support | 매 ticket 의 owner |
+| Billing | 매 payment account |
+| Shipping | 매 delivery address |
+| Marketing | 매 segment member |

-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+→ 매 같은 entity 가, 매 different attribute / behavior.

-**언제 이 지식을 쓰는가:**
- *(TODO)*
+### Ubiquitous Language
+- 매 같은 word = 매 같은 meaning (within BC).
+- 매 dev + PO + designer + business 의 share.
+- 매 documentation, code, conversation 의 일관.

-**언제 쓰면 안 되는가:**
- *(TODO)*
+### Context Map (relationship type)
+| 관계 | 설명 |
+|---|---|
+| Shared Kernel | 매 공통 model 의 share (위험) |
+| Customer-Supplier | 매 upstream-downstream 의 협력 |
+| Conformist | 매 downstream 의 upstream 의 그대로 따름 |
+| Anti-Corruption Layer (ACL) | 매 boundary 의 translation |
+| Open Host Service | 매 well-defined API |
+| Published Language | 매 cross-context 의 standard format |
+| Separate Ways | 매 integration X |
+| Big Ball of Mud | 매 unstructured (anti-pattern) |

-## 🧪 검증 상태 (Validation)
+### 매 size 의 trade-off
+- 매 너무 작 → 매 distributed monolith.
+- 매 너무 큼 → 매 god service.
+- 매 sweet spot: 매 single team 의 own 의 가능.

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+### 매 modular monolith vs microservice
+| 접근 | When |
+|---|---|
+| Modular monolith | 매 boundary 의 unclear / 매 small team |
+| Microservice | 매 boundary 의 stable / 매 scale need |
+| Strangler Fig | 매 legacy 의 incremental migrate |

-## 🧬 중복 검사 (Duplicate Check)
+→ "Microservices first" 의 보통 wrong. 매 modular monolith → 매 split.

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+### 매 strategic vs tactical DDD
+- **Strategic**: 매 BC + 매 context map.
+- **Tactical**: 매 entity / value object / aggregate / domain event.

-## 🕓 변경 이력 (Changelog)
+### Event Storming
+- 매 BC discovery 의 workshop.
+- 매 domain event 의 sticky note.
+- 매 aggregate / actor / policy 의 emerge.
+- 매 modern DDD 의 entry.

-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+### 매 modern variant
+- 매 DDD-Lite (lightweight).
+- 매 Team Topologies (Stream-Aligned + Platform + Enabling + Complicated Subsystem).
+- 매 Conway's Law: 매 architecture = 매 organization.

-## 💻 코드 패턴 (Code Patterns)
+## 💻 패턴

-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
+### Module per BC (TS)
+```
+src/
+├── billing/          # 매 BC 1
+│   ├── domain/       # 매 entity, value object
+│   ├── application/  # 매 use case
+│   └── infrastructure/
+│
+├── shipping/         # 매 BC 2
+│   ├── domain/
+│   ├── application/
+│   └── infrastructure/
+│
+└── shared/           # 매 ACL / published language
+    └── events/
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+### Anti-Corruption Layer
+```ts
+// 매 external system (legacy CRM) 의 different model
+import { LegacyCRMClient } from './legacy-crm';

-**선택 A를 써야 할 때:**
- *(TODO)*
+interface DomainCustomer {
+  id: CustomerId;
+  email: Email;
+  preferences: Preferences;
+}

-**선택 B를 써야 할 때:**
- *(TODO)*
+// 매 ACL — 매 legacy → 매 our domain
+class CRMAdapter {
+  constructor(private legacy: LegacyCRMClient) {}
+  
+  async getCustomer(id: string): Promise<DomainCustomer> {
+    const raw = await this.legacy.fetchUser(id);  // 매 messy
+    return {
+      id: CustomerId.parse(raw.user_id_v2),
+      email: Email.parse(raw.contact?.email_addr ?? raw.email),
+      preferences: this.translatePrefs(raw.flags),
+    };
+  }
+  
+  private translatePrefs(flags: number): Preferences {
+    // 매 magic bitmap → 매 typed
+    return { newsletter: !!(flags & 1), sms: !!(flags & 2) };
+  }
+}
+```

-**기본값:**
-> *(TODO)*
+### Domain event (cross-BC communication)
+```ts
+// 매 billing BC
+class Order {
+  pay(amount: Money) {
+    // ... domain logic
+    this.events.push(new OrderPaid(this.id, amount));
+  }
+}

-## ❌ 안티패턴 (Anti-Patterns)
+// 매 published language
+type OrderPaid = {
+  type: 'order.paid';
+  version: '1.0';
+  orderId: string;
+  amount: { value: number; currency: string };
+  occurredAt: string;
+};

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+// 매 shipping BC 의 subscribe
+@EventHandler('order.paid')
+class StartShipment {
+  async handle(event: OrderPaid) {
+    await this.shipmentRepo.create({ orderId: event.orderId });
+  }
+}
+```
+
+### Event Storming output (sticky note)
+```
+[Domain Event] OrderPlaced
+[Actor] Customer
+[Aggregate] Order
+[Command] PlaceOrder
+[Policy] When OrderPlaced → SendConfirmation
+[External System] Payment Gateway
+[Read Model] OrderHistory
+```
+
+### Module boundary check (dependency-cruiser)
+```js
+module.exports = {
+  forbidden: [
+    {
+      name: 'no-cross-bc-import',
+      severity: 'error',
+      from: { path: '^src/billing' },
+      to: { path: '^src/(?!billing|shared)' },
+    },
+    {
+      name: 'shared-events-only',
+      severity: 'error',
+      from: { path: '^src/(billing|shipping)' },
+      to: { path: '^src/(billing|shipping)/(?!.*\\.events\\.ts)' },
+    },
+  ],
+};
+```
+
+### Modular monolith → microservice extraction
+```
+1. 매 BC 의 module 의 만들기 (modular monolith).
+2. 매 module 의 internal 의 사용 의 measure.
+3. 매 stable boundary 의 confirm.
+4. 매 module 의 service 의 extract:
+   - 매 module API 의 → REST / gRPC / event.
+   - 매 in-process call 의 → network call.
+   - 매 separate database (own data).
+5. 매 deployment / monitoring 의 separate.
+```
+
+### Strategic Design Workshop
+```yaml
+# 매 BC 의 workshop output
+bounded_contexts:
+  - name: Billing
+    team: Payments Team
+    ubiquitous_language:
+      - Invoice: "매 customer 의 charge 된 amount"
+      - LineItem: "매 invoice 의 row"
+    aggregates: [Invoice, Subscription]
+    upstream: []
+    downstream: [Notification, Reporting]
+    relationship: { Reporting: 'OHS' }
+  
+  - name: Notification
+    upstream: [Billing, Shipping]
+    relationship: { Billing: 'Conformist' }
+```
+
+## 🤔 결정 기준
+| 상황 | Approach |
+|---|---|
+| New project | Modular monolith + clear BC |
+| Legacy mess | Strangler Fig + extract BC 의 1 by 1 |
+| Cross-BC sync need | Event-driven |
+| Cross-BC sync stronger | API + ACL |
+| Single team | 1 BC |
+| Multi-team | 1 BC / team |
+| External system | ACL |
+| Published format need | Published Language |
+
+**기본값**: Modular monolith → 매 BC 의 stabilize → 매 microservice.
+
+## 🔗 Graph
+- 부모: [[Domain-Driven-Design]] · [[Software-Architecture]]
+- 변형: [[Ubiquitous-Language]] · [[Context-Map]] · [[Anti-Corruption-Layer]]
+- 응용: [[Microservices]] · [[Modular-Monolith]] · [[Event-Storming]] · [[Strangler-Fig]]
+- Adjacent: [[Aggregate-Root]] · [[Conway-Law]] · [[Team-Topologies]] · [[Anaemic-Domain-Model]]
+
+## 🤖 LLM 활용
+**언제**: 매 large system design. 매 microservice boundary. 매 legacy refactor planning. 매 team-structure align.
+**언제 X**: 매 simple CRUD. 매 single-team prototype.
+
+## ❌ 안티패턴
+- **God BC**: 매 모든 logic 의 한 곳.
+- **Cross-BC entity 의 share**: 매 coupling.
+- **Distributed monolith**: 매 too small BC.
+- **No ubiquitous language**: 매 confusion.
+- **Premature microservice**: 매 boundary unclear.
+- **No ACL** (external integration): 매 corruption.
+- **Database 의 share** (cross-BC): 매 coupling.
+
+## 🧪 검증 / 중복
+- Verified (Eric Evans DDD, Vaughn Vernon Implementing DDD, Sam Newman Microservices).
+- 신뢰도 A.
+- Related: [[Domain-Driven-Design]] · [[Microservices]] · [[Event-Storming]] · [[Conway-Law]] · [[Architecture-Styles]].
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — context map + Event Storming + 매 ACL / domain event / boundary check code |