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

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-bounded-contexts	Bounded Contexts (DDD)	10_Wiki/Topics	verified	self	bounded context BC ubiquitous language context mapping domain-driven design ACL anti-corruption layer	none	A	0.93	applied	ddd bounded-context ubiquitous-language context-map microservices anti-corruption-layer domain-modeling		2026-05-10	pending	language framework language-agnostic 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

// 매 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)

// 매 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)

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

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