2nd/10_Wiki/Topics/AI_and_ML/Bounded Contexts.md

---
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 |