docs(10_Wiki): Topic_Business/General/Graphic/Programming을 Topics/ 하위로 이동
최상위 10_Wiki/Topic_*였던 4개 카테고리 폴더를 10_Wiki/Topics/Topic_* 로 재배치. 콘텐츠 변경 없음(순수 폴더 이동) — Topics/ 하위 나머지 폴더는 이미 지난 커밋에서 전부 정리된 상태(잔존 항목은 에이전트 운영 상태 및 사용자가 보존을 요청한 업데이트0615/무제 3.canvas 뿐).
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,272 @@
|
||||
---
|
||||
id: wiki-2026-0508-bounded-contexts
|
||||
title: Bounded Contexts (DDD)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
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.93
|
||||
verification_status: applied
|
||||
tags: [ddd, bounded-context, ubiquitous-language, context-map, microservices, anti-corruption-layer, domain-modeling]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: language-agnostic
|
||||
framework: DDD / Clean Architecture
|
||||
---
|
||||
|
||||
# Bounded Contexts
|
||||
|
||||
## 📌 한 줄 통찰
|
||||
> **"매 모두 의 language = 매 아무도 의 language"**. 매 specific domain 의 internal 의 의미 boundary. 매 같은 word ('Account' = bank 의 계좌 vs login 의 ID) 의 isolation. 매 DDD 의 핵심. 매 microservice boundary 의 base.
|
||||
|
||||
## 📖 핵심
|
||||
|
||||
### 매 정의 (Eric Evans)
|
||||
- 매 model 의 explicit boundary.
|
||||
- 매 ubiquitous language 의 작동 region.
|
||||
- 매 team / responsibility 의 align.
|
||||
|
||||
### 매 typical example
|
||||
| Context | "Customer" 의 의미 |
|
||||
|---|---|
|
||||
| Sales | 매 prospect / lead |
|
||||
| Support | 매 ticket 의 owner |
|
||||
| Billing | 매 payment account |
|
||||
| Shipping | 매 delivery address |
|
||||
| Marketing | 매 segment member |
|
||||
|
||||
→ 매 같은 entity 가, 매 different attribute / behavior.
|
||||
|
||||
### Ubiquitous Language
|
||||
- 매 같은 word = 매 같은 meaning (within BC).
|
||||
- 매 dev + PO + designer + business 의 share.
|
||||
- 매 documentation, code, conversation 의 일관.
|
||||
|
||||
### 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) |
|
||||
|
||||
### 매 size 의 trade-off
|
||||
- 매 너무 작 → 매 distributed monolith.
|
||||
- 매 너무 큼 → 매 god service.
|
||||
- 매 sweet spot: 매 single team 의 own 의 가능.
|
||||
|
||||
### 매 modular monolith vs microservice
|
||||
| 접근 | When |
|
||||
|---|---|
|
||||
| Modular monolith | 매 boundary 의 unclear / 매 small team |
|
||||
| Microservice | 매 boundary 의 stable / 매 scale need |
|
||||
| Strangler Fig | 매 legacy 의 incremental migrate |
|
||||
|
||||
→ "Microservices first" 의 보통 wrong. 매 modular monolith → 매 split.
|
||||
|
||||
### 매 strategic vs tactical DDD
|
||||
- **Strategic**: 매 BC + 매 context map.
|
||||
- **Tactical**: 매 entity / value object / aggregate / domain event.
|
||||
|
||||
### Event Storming
|
||||
- 매 BC discovery 의 workshop.
|
||||
- 매 domain event 의 sticky note.
|
||||
- 매 aggregate / actor / policy 의 emerge.
|
||||
- 매 modern DDD 의 entry.
|
||||
|
||||
### 매 modern variant
|
||||
- 매 DDD-Lite (lightweight).
|
||||
- 매 Team Topologies (Stream-Aligned + Platform + Enabling + Complicated Subsystem).
|
||||
- 매 Conway's Law: 매 architecture = 매 organization.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### 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/
|
||||
```
|
||||
|
||||
### Anti-Corruption Layer
|
||||
```ts
|
||||
// 매 external system (legacy CRM) 의 different model
|
||||
import { LegacyCRMClient } from './legacy-crm';
|
||||
|
||||
interface DomainCustomer {
|
||||
id: CustomerId;
|
||||
email: Email;
|
||||
preferences: Preferences;
|
||||
}
|
||||
|
||||
// 매 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) };
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Domain event (cross-BC communication)
|
||||
```ts
|
||||
// 매 billing BC
|
||||
class Order {
|
||||
pay(amount: Money) {
|
||||
// ... domain logic
|
||||
this.events.push(new OrderPaid(this.id, amount));
|
||||
}
|
||||
}
|
||||
|
||||
// 매 published language
|
||||
type OrderPaid = {
|
||||
type: 'order.paid';
|
||||
version: '1.0';
|
||||
orderId: string;
|
||||
amount: { value: number; currency: string };
|
||||
occurredAt: string;
|
||||
};
|
||||
|
||||
// 매 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]] · [[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]] · [[Software Architecture Styles]].
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — context map + Event Storming + 매 ACL / domain event / boundary check code |
|
||||
Reference in New Issue
Block a user