Strategic Design

Strategic Design(전략적 설계)

Strategic Design (전략적 설계) 는 Eric Evans 가 제시한 Domain-Driven Design (도메인 주도 설계) 의 고수준 설계 접근법이다.
복잡한 비즈니스 도메인을 명확히 구분된 Bounded Context (경계 컨텍스트) 들로 분해하고, 각 컨텍스트 내에서 Ubiquitous Language (공통 언어) 를 구축하며, Context Map (컨텍스트 맵) 을 통해 컨텍스트 간 관계를 정의하여 대규모 소프트웨어 시스템의 복잡성을 체계적으로 관리한다.
이 그림 위에서 Tactical Design(전술 설계) 은 각 바운디드 콘텍스트 내에서 엔티티, VO, 어그리게이트, 리포지토리, 도메인 서비스, 도메인 이벤트 등의 빌딩 블록을 사용하여 도메인 로직을 구현하고 테스트, CI/CD 와 연계하여 구현 완성도를 높인다.

핵심 개념

Strategic Design은 복잡한 도메인을 분해하고, 하위 도메인 간의 관계를 명확하게 정의하여 **조직 구조, 소프트웨어 구조, 팀 협업 구조 간의 정렬 (alignment)**을 도출하는 고수준 설계 접근 방식이다.

주요 개념

Domain & Subdomain

• 도메인을 이해하고 분해하는 것이 모든 설계의 출발점
• 도메인은 세 가지 유형으로 분류

Bounded Context (BC)

• 모델이 일관성을 가지는 명확한 경계 (Context) 를 의미
• BC 는 하나의 도메인 모델, 하나의 언어, 하나의 구현 책임 단위
• Microservice 의 자연스러운 단위

핵심 포인트:

• 동일한 단어도 서로 다른 BC 에서 다르게 해석될 수 있음
• 하나의 서브도메인에 여러 BC 가 존재할 수도 있음

Ubiquitous Language

• 도메인 전문가와 개발자 간 공통 언어
• 모델, 코드, 문서, 대화에 동일한 용어 사용
• 개념 간 불일치를 방지하고, 설계에 일관성 확보

Context Map

• 여러 Bounded Context 간의 관계를 시각화
• 통합 전략, 협력 방식, 의존성을 명시함

주요 Context Mapping Patterns

실무 구현 요소

분석 및 설계 기법

조직적 대응

• 도메인별 팀 조직 (Team Topologies 와 결합 시 효과적)
• 각 Bounded Context 단위로 팀 분리 → Conway’s Law 대응
• 컨텍스트 간 API 또는 메시징 기반 통합 전략 적용

아키텍처 연계

• 각 BC 는 독립적인 배포/개발 단위 (→ Microservice Architecture 와 호환)
• ACL 적용으로 느슨한 결합 유지
• Context Map 은 기술적 아키텍처 구성의 기초 자료로 활용

정리

graph TD
  Domain[Domain]
  Domain --> Core[Core Domain]
  Domain --> Supporting[Supporting Domain]
  Domain --> Generic[Generic Domain]

  Core --> BC1[Bounded Context A]
  Supporting --> BC2[Bounded Context B]
  Generic --> BC3[Bounded Context C]

  BC1 --> UL1[Ubiquitous Language]
  BC2 --> UL2[Ubiquitous Language]
  BC3 --> UL3[Ubiquitous Language]

  BC1 --> CM[Context Map]
  BC2 --> CM
  BC3 --> CM

  CM --> SK[Shared Kernel]
  CM --> ACL[Anticorruption Layer]
  CM --> CS[Customer/Supplier]
  CM --> CON[Conformist]

목적 및 필요성

• 비즈니스 중심의 문제 영역 (Problem Space) 이해 및 핵심 도메인 식별.
• 도메인 전문가–개발자 간 이해 격차 해소 위해 공통 언어 (Ubiquitous Language) 구축.
• 컨텍스트 경계 설정으로 복잡도 분리, 팀 독립성·책임성 확보.

주요 기능 및 역할

1. 도메인 분석 기능

   • Problem Space 분석: 비즈니스 문제 영역을 체계적으로 분석
   • Subdomain 식별: 도메인을 Core, Supporting, Generic 으로 분류
   • 우선순위 결정: 비즈니스 가치에 따른 투자 우선순위 설정

2. 모델 설계 기능

   • Bounded Context 정의: 명확한 모델 경계 설정
   • Ubiquitous Language 구축: 팀 전체가 공유하는 도메인 언어 개발
   • Domain Model 설계: 각 컨텍스트별 최적화된 도메인 모델 구성

3. 통합 관리 기능

   • Context Mapping: 컨텍스트 간 관계와 통합 방식 정의
   • Integration Pattern 선택: 상황에 적합한 통합 패턴 적용
   • 의존성 관리: 컨텍스트 간 의존성을 명시적으로 관리

특징

1. 고수준 접근법

   • Big Picture 관점: 전체 시스템을 조감하는 거시적 시각
   • 비즈니스 중심: 기술보다 비즈니스 가치를 우선시
   • 전략적 사고: 장기적 관점에서의 시스템 설계

2. 협업 중심

   • 다학제적 접근: 도메인 전문가, 개발자, 아키텍트의 협업
   • 지속적 학습: 도메인 지식의 지속적 발견과 정제
   • 공통 언어: 모든 이해관계자가 공유하는 의사소통 도구

3. 경계 중심 설계

   • 명시적 경계: 모델의 적용 범위를 명확히 정의
   • 컨텍스트 독립성: 각 컨텍스트의 자율성 보장
   • 관계 명시: 컨텍스트 간 관계를 명시적으로 정의

핵심 원칙

1. 모델 무결성 원칙

   • 각 Bounded Context 내에서는 단일하고 일관된 모델 유지
   • 모델의 개념적 무결성을 해치는 요소들 제거

2. 경계 명시 원칙

   • 모델이 적용되는 범위를 명확히 정의
   • 경계를 넘나드는 개념들에 대한 명시적 변환 정의

3. 공통 언어 원칙

   • 팀 전체가 공유하는 Ubiquitous Language 구축
   • 코드, 문서, 대화에서 일관된 언어 사용

4. 비즈니스 가치 중심 원칙

   • Core Domain 에 최대 투자 집중
   • 비즈니스 우선순위에 따른 자원 배분

5. 팀 자율성 원칙

   • 각 팀이 자신의 컨텍스트 내에서 독립적으로 작업
   • 팀 간 의존성 최소화

주요 원리

flowchart TD
  Problem-Space[문제 공간] --> Subdomain
  Subdomain --> BoundedContext
  BoundedContext --> UbiquitousLanguage
  BoundedContext --> ContextMap
  ContextMap --> IntegrationPatterns
  IntegrationPatterns --> Implementation

• Problem-Space: 도메인 분석
• Subdomain 식별: 핵심/지원/일반
• Context 설정: 모듈화
• 공통 언어 정의: 코드·사람 공유
• Context Map: 시스템 간 관계 자동화
• 통합 패턴: 경계 간 통신 전략
• 실행 연계: Tactical Design 과 구현 연동

분해 원리 (Decomposition Principle)

개념:

• 복잡한 도메인을 의미 있는 하위 도메인 (Subdomain) 으로 분해
• 각 Subdomain 을 Bounded Context 로 구체화하여 독립된 책임과 모델을 갖도록 설계
• 도메인 간 경계를 명확히 하여, 의미적 응집도 와 기술적 독립성 확보

실무 포인트:

• 하위 도메인마다 모델과 전략이 달라야 하며, 같은 아키텍처 스타일을 강제하지 않음
• 각 Subdomain 에 맞는 전략적 우선순위 (Core Domain 은 집중 투자)

graph TD
    A[Large Domain] --> B[Core Subdomain]
    A --> C[Supporting Subdomain]
    A --> D[Generic Subdomain]
    B --> E[Bounded Context 1]
    C --> F[Bounded Context 2]
    D --> G[Bounded Context 3]

통합 원리 (Integration Principle)

개념:

• 각각의 Bounded Context 는 고립되어 있지만, 전체 시스템에서 협력해야 함
• Context Mapping Patterns을 활용하여 경계 간 통합 방식을 정의

실무 포인트:

• 핵심 도메인 보호를 위해 ACL(Anti-Corruption Layer) 도입
• 하위 도메인의 중요도에 따라 종속성 방향, API 형태, 동기/비동기 방식 결정

주요 패턴:

graph LR
    A[Upstream Context] -->|Partnership| B[Downstream Context]
    C[Supplier Context] -->|Customer-Supplier| D[Consumer Context]
    E[Host Context] -->|Open Host Service| F[Client Context]
    G[Context A] -.->|Separate Ways| H[Context B]

언어 통일 원리 (Ubiquitous Language Principle)

개념:

• 도메인 전문가와 개발자가 동일한 언어로 소통
• 코드, 테스트, 문서, 회의에서 동일한 단어와 개념 사용

실무 포인트:

• 코드에 도메인 용어가 그대로 반영되어야 함
• 모델링 단계에서 나온 용어가 구현 코드까지 이어져야 함

1
2
3
4

Domain Expert ↔ Ubiquitous Language ↔ Developer
      ↕                ↕                 ↕
   Business        Code Model        Software
   Process                          Implementation

전략적 정렬 원리 (Strategic Alignment Principle)

개념:

• 조직 구조, 도메인 구조, 시스템 구조를 정렬 (Alignment) 하여 일관성 있게 운영
• Conway’s Law 에 기반: 시스템 구조는 조직의 커뮤니케이션 구조를 반영하게 됨

실무 포인트:

• 도메인별 팀 구성 → 팀과 Bounded Context 1:1 매핑
• 전략적 중요도 (Core Domain) 높은 팀에 리소스 집중

예시 정렬 모델:

graph TD
    OrgA["Team A (Core Domain)"] --> BCA[Bounded Context A]
    OrgB["Team B (Supporting Domain)"] --> BCB[Bounded Context B]
    OrgC["Team C (Generic Domain)"] --> BCC[Bounded Context C]

경계 진화 원리 (Evolution of Boundaries Principle)

개념:

• 도메인 경계 (Bounded Context) 는 고정된 것이 아니며, 시간이 지남에 따라 비즈니스 변화나 인프라 요구에 따라 재조정될 수 있음
• 이를 통해 도메인 모델의 지속적 리팩토링 가능

실무 포인트:

• 도메인 리더와 협업하여 주기적 도메인 리디자인 워크숍 진행
• Context Map 을 지속적으로 업데이트

작동 원리

도메인 발견 과정

sequenceDiagram
    participant DE as Domain Expert
    participant A as Architect
    participant D as Developer
    
    DE->>A: 비즈니스 프로세스 설명
    A->>D: 도메인 모델 초안 작성
    D->>DE: 모델 검증 요청
    DE->>A: 피드백 제공
    A->>D: 모델 정제
    Note over DE,D: 반복적 정제 과정

Bounded Context 식별 과정

1. 언어 경계 식별: 용어의 의미가 변하는 지점 찾기
2. 팀 경계 고려: 조직 구조와 의사소통 패턴 분석
3. 기술 경계 평가: 기술적 제약사항과 요구사항 고려
4. 비즈니스 기능 분석: 응집도가 높은 기능 그룹 식별

Context Mapping 과정

1. 컨텍스트 식별: 모든 Bounded Context 나열
2. 관계 분석: 컨텍스트 간 의존성과 상호작용 분석
3. 패턴 선택: 각 관계에 적합한 통합 패턴 선택
4. 맵 작성: 시각적 컨텍스트 맵 작성

구조 및 아키텍처

graph TB
    subgraph "Problem Space"
        PS[Problem Space]
        CD[Core Domain]
        SD[Supporting Domain]
        GD[Generic Domain]
        PS --> CD
        PS --> SD
        PS --> GD
    end
    
    subgraph "Solution Space"
        SS[Solution Space]
        BC1[Bounded Context 1]
        BC2[Bounded Context 2]
        BC3[Bounded Context 3]
        SS --> BC1
        SS --> BC2
        SS --> BC3
    end
    
    subgraph "Language Layer"
        UL[Ubiquitous Language]
        UL --> BC1
        UL --> BC2
        UL --> BC3
    end
    
    subgraph "Integration Layer"
        CM[Context Map]
        CM --> BC1
        CM --> BC2
        CM --> BC3
    end

Problem Space (문제 공간)

정의:

• Problem Space는 소프트웨어가 해결하고자 하는 비즈니스 문제 도메인을 분석하고 정의하는 영역이다.
• " 무엇을 해결할 것인가?" 에 초점을 맞추며, 도메인의 구조와 서브도메인을 파악하는 것이 핵심이다.

주요 목적

• 비즈니스 목표, 정책, 흐름 등을 이해하고 구체화
• 도메인을 Core / Supporting / Generic 서브도메인으로 분류
• 도메인 전문가와의 협업을 통해 의미 있는 경계를 식별

핵심 질문:

• 어떤 도메인이 존재하는가?
• 어떤 도메인이 비즈니스에 가장 중요한가?
• 이 문제를 해결하려면 어떤 서브도메인이 필요한가?

실무 적용 포인트:

추가 분석:

• 문제 공간은 비즈니스 전략과 정렬되는 방향으로 기능별 분할이 이루어져야 함.
• 문제 도메인의 이해 부족은 잘못된 컨텍스트 설계로 이어짐.

Subdomain

Subdomain 은 전체 도메인 안에서 특정한 목적이나 역할을 수행하는 하위 영역이며, 비즈니스 로직이 명확하게 구분될 수 있는 의미 단위의 경계이다.

필요성:

Subdomain 분류

graph TD
    A[비즈니스 도메인] --> B[하위 도메인 분리]
    B --> C1[핵심 하위 도메인]
    B --> C2[지원 하위 도메인]
    B --> C3[일반 하위 도메인]
    C1 --> D1[Bounded Context]
    C2 --> D2[Bounded Context]
    C3 --> D3[Bounded Context]
    D1 --> E[Context Map]
    D2 --> E
    D3 --> E

도메인 → 하위 도메인 → Bounded Context → Context Map 흐름

예시: 온라인 교육 플랫폼 (LMS)

Subdomain vs. Bounded Context

Subdomain 은 " 무엇을 해야 하는지 " 를 설명하고, **Bounded Context 는 " 어떻게 구현할 것인지 " 를 결정하는 경계이다. **

Solution Space (해결 공간)

정의:

• Solution Space는 Problem Space 에서 정의된 문제를 해결하기 위한 소프트웨어 시스템 설계 공간이다.
• *" 어떻게 해결할 것인가?"* 를 다루며, Bounded Context 와 각 컨텍스트 간 관계 정의를 포함한다.

주요 목적:

• 경계를 명확히 설정하고, 기술적 책임 분리
• 각 문제 영역에 적합한 설계 패턴과 아키텍처 적용
• 팀 구성, 모듈화, 배포 전략과 연계

핵심 구성 요소:

• 여러 Bounded Context들의 집합
• 각 컨텍스트는 특정 Subdomain 에 매핑됨
• 통합 방식은 Context Map 으로 표현됨

실무 적용 포인트:

구성 요소:

추가 분석:

• Solution Space 는 기술적 현실성과 조직 구조가 ** 정렬 (Alignment)** 되어야 효과적.
• " 도메인 중심 설계 vs 기술 중심 설계 " 충돌 방지를 위한 전략적 조율 필요.

Bounded Context

정의:

• Bounded Context는 특정 도메인 모델이 적용되는 명확한 논리적 경계를 의미한다.
• 같은 도메인이라도 다른 Bounded Context 에서 다른 의미로 사용될 수 있다.

주요 목적:

• 모델의 일관성과 무결성 유지
• 도메인 전문가와 개발자 간 소통 단위
• 코드, 모델, 언어, 테스트, 문서의 범위를 일치시킴

특징:

• 하나의 BC 는 하나의 Ubiquitous Language를 갖는다
• 팀 구조, 데이터베이스 스키마, 배포 단위로도 구분됨

구성 요소:

Bounded Context 경계 식별 방법:

• 도메인 이벤트 중심 식별: Event Storming 등 워크숍을 통해 도메인 이벤트와 책임 주체를 시각화하여 자연스러운 경계 도출.
• Ubiquitous Language: 용어의 의미가 달라지는 지점을 경계로 삼아 BC 를 구분.
• 조직 구조 및 책임: 팀의 책임과 업무 흐름, Conway’s Law 에 따라 조직 구조와 BC 경계를 일치시키는 것이 효과적.
• 데이터 독립성: 데이터 모델이 독립적으로 진화할 수 있는 범위를 BC 로 설정.

경계 식별 기준:

실무 적용 포인트:

실무 적용 확장:

Bounded Context 와 Microservice 의 차이

• BC ≠ Microservice: BC 는 도메인 경계, Microservice 는 배포 단위로, 둘이 반드시 1:1 로 매핑되는 것은 아님.
• BC 내 다수의 Microservice: 하나의 BC 가 여러 Microservice 로 구현될 수 있으며, 반대로 여러 BC 가 하나의 서비스에 섞이면 도메인 혼란이 발생.

추가 분석:

• Bounded Context 는 하나의 도메인 서브시스템, 조직 단위, 배포 단위가 일치할수록 효과적.
• 내부 설계는 Tactical DDD 로 이어짐 (Entity, VO, Service, Repository 등).

Ubiquitous Language

정의:

• Ubiquitous Language란 도메인 전문가와 개발자가 공통적으로 사용하는 도메인 중심의 언어 체계
• 설계, 코드, 테스트, 문서, 대화 등 모든 곳에 일관되게 적용되는 모델링 언어.

• 도메인 지식이 정확하게 구현에 반영되도록 하는 소통 도구
• 해당 언어는 단순한 용어 수준이 아니라 도메인 개념, 규칙, 흐름을 포괄함

주요 목적:

핵심 질문:

• 도메인 전문가와 개발자가 사용하는 용어가 동일한가?
• 코드, 문서, 테스트, 대화에서 같은 개념이 일관된 의미로 표현되는가?
• 모델의 용어는 도메인을 진정으로 반영하고 있는가?
• 설계에서 발생하는 오해나 해석 오류가 언어 불일치에서 기인하지 않는가?

실무 적용 포인트:

구성 요소:

Context Map (컨텍스트 맵)

정의:

• Context Map은 여러 Bounded Context 간의 관계와 통합 방식을 시각화한 설계 도구이다.
• 전략적 통합 패턴 (예: ACL, Shared Kernel 등) 을 기반으로 컨텍스트 간 상호작용을 정의한다.

주요 목적:

• 시스템 전체 구조 파악
• 컨텍스트 간 협력, 종속성, 커뮤니케이션 흐름 정의
• 조직 구조와 시스템 경계의 정렬

실무 적용 포인트:

구성 요소:

추가 분석:

• 컨텍스트 맵은 도식적 표현 (모델링) 뿐 아니라 운영 전략의 기술적 표현 역할도 수행.
• 팀 간 협업 프로세스, 제품 개발 흐름의 일관성을 높이는데 핵심적 기여.

Upstream, Downstream 그리고 Midway

Context Mapping에서 매우 중요한 개념으로, 두 컨텍스트 간 통신/통합 구조를 설계할 때 어떤 쪽이 주도권을 가지는지, 어떤 쪽이 종속되는지, 혹은 대등한 관계인지를 명확히 하기 위해 사용된다.

• Upstream 은 계약 (API, 메시지, 스키마 등) 을 주도하고, Downstream 은 해당 계약을 기반으로 동작해야 한다.
• Upstream 의 변화는 Downstream 에 직접적 영향을 준다.

Upstream, Downstream 그리고 Midway 의 관계:

1
2
3

Upstream  →  Downstream
       ↕
     Midway

• Upstream: 표준 API 제공, 명세 주도, 변화 발생 시 영향 전파
• Downstream: Upstream 에 맞춰 적응, 변화를 수용
• Midway: 상호 협의로 모델/기능 설계, 동등한 책임과 권한

실무 적용 포인트:

• Upstream 은 서비스 제공자로서 책임 있는 인터페이스 관리와 버전 전략이 중요
• Downstream 은 소비자로서 변화에 유연하게 대응할 수 있는 구조 (예: ACL, Adapter) 가 필요
• Midway 는 협력 중심으로 커뮤니케이션 프로세스, 계약 문서화, 모델 공유 전략이 핵심

전략적 시사점:

• Upstream: 자율적 설계와 진화 가능하지만 Downstream 에 부담 전가 가능
• Downstream: 안정적인 API 기반 소비 가능하지만 Upstream 변화에 유연성 필요
• Midway: 협력이 필요한 경우 협의기구ㆍ공유 모델로 상호 조율 가능

주요 통합 패턴

Open Host Service (OHS)

• 활용 사례: 결제 시스템, 사용자 인증 서비스 등에서 공식 REST API, gRPC, GraphQL 등 표준 프로토콜로 외부에 서비스 제공.

• 사용 예시: 드론 배송 서비스에서 배송 (Shipping) 컨텍스트가 OpenAPI/Swagger 로 REST API 를 공개하여, 다른 컨텍스트 (예: 사용자 계정, 드론 관리) 가 표준화된 방식으로 접근.

• 코드 예시:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  # openapi.yaml 일부 예시 paths: /delivery: get: summary: "배송 목록 조회" responses: '200': description: "성공" content: application/json: schema: type: array items: $ref: '#/components/schemas/Delivery' components: schemas: Delivery: type: object properties: id: type: integer status: type: string

  • 명세 기반 인터페이스: OHS 의 대표적인 문서화 방법
  • Swagger UI 또는 Codegen 을 통해 클라이언트 자동 생성 가능
  • API 안정성과 계약 유지에 기여

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel, Field from typing import List app = FastAPI(title="Shipping Service", version="1.0") class Delivery(BaseModel): id: int = Field(..., example=1) status: str = Field(..., example="in-transit") def get_current_user(): # 인증 로직 생략 (JWT 또는 OAuth2) return "external_service_consumer" @app.get("/v1/delivery", response_model=List[Delivery]) def get_deliveries(user=Depends(get_current_user)): try: return [ {"id": 1, "status": "delivered"}, {"id": 2, "status": "in-transit"} ] except Exception as e: raise HTTPException(status_code=500, detail=str(e))

  • Depends → 인증/인가 처리
  • tags → Swagger 그룹화
  • HTTPException → 명시적 에러 계약
  • FastAPI 는 자체적으로 OpenAPI 명세를 /docs 로 제공 → OHS 에 최적
  • 표준 HTTP 방식 사용 + JSON 응답 → OHS 의 ’ 명시적 공개 API’ 와 일치
  • 실무적으로도 많이 사용되는 구조

Published Language

• 활용 사례: 금융 (ISO 20022), 물류 (EDI), 플랫폼 간 통신에서 명시적 메시지 포맷 (Avro, Protobuf) 을 정의하여 상호 시스템 간의 데이터 교환에 활용.

• 사용 예시: 드론 배송 시스템이 delivery.proto 메시지 스키마를 Schema Registry 또는 공유 Git 저장소에 공개하고, 주문 시스템이 해당 메시지 형식을 기준으로 Kafka 이벤트를 발행하거나 gRPC 호출을 수행.

• 코드 예시 (Protobuf 메시지 정의):

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  syntax = "proto3"; message Address { string street = 1; string city = 2; string zipCode = 3; } message DeliveryRequest { string userId = 1; Address address = 2; string packageId = 3; int32 version = 4; }

  • 메시지 포맷을 명확히 정의하고, 버전 관리 체계화.
  • proto3 명세로 최신 protobuf 지원
  • 필드 번호 지정 → 향후 변경 대비 확장성 우수
  • 메시지 구조 명확 → 여러 언어에서 동일 구조 생성 가능 (Java, Python, JS 등)

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  # delivery_pb2.py 로 컴파일된 Protobuf 메시지 사용 from delivery_pb2 import DeliveryRequest, Address req = DeliveryRequest( userId="user-123", packageId="pkg-456", address=Address( street="123 Drone St", city="Seoul", zipCode="12345" ), version=1 ) # Serialize (Kafka 전송 or gRPC 호출에 활용) payload = req.SerializeToString()

Partnership

• 활용 사례: 대형 금융사와 핀테크 기업 간 협업에서, 공동으로 비즈니스 로직과 계약 명세 (API, 메시지 포맷 등) 를 설계하고, 양측이 동등한 책임을 지며 통신 및 개발을 수행하는 경우.

• 사용 예시: 두 개발 팀이 **공동의 API 명세 (OpenAPI)**와 **공통 메시지 스키마 (JSON Schema, Protobuf 등)**를 협의하고, 이를 버전 관리되는 명세 저장소에서 관리. 각 팀은 별도의 시스템을 운영하지만, 서로의 API 변화에 대한 영향을 고려하여 동시 릴리스 계획을 수립하고, 계약 기반 테스트 (Pact, Swagger Diff) 등을 함께 유지.

• 코드 예시:

  1 2 3 4 5 6 7 8

  # OpenAPI 명세 (공동 작성 및 유지) paths: /customer: get: summary: 고객 정보 조회 responses: 200: description: 성공

  1 2 3 4 5 6 7 8

  # A 시스템 (핀테크 측) @app.route('/customer/<id>') def get_customer(id): return {"id": id, "name": "Alice"} # B 시스템 (은행 측) resp = requests.get(f"http://fintech-service/customer/123") customer = resp.json()

  • 양방향 API 통신
  • 서로 다른 시스템이 서로에게 의존
  • 데이터/도메인 설계는 분리, 하지만 공동 목표를 위해 지속적 협의

Shared Kernel

• 활용 사례: 고객 시스템과 결제 시스템이 공통된 인증 도메인 모델과 정책 유효성 검증 로직을 공유하며, 이 코드를 공동으로 관리하고 유지함.

• 사용 예시: 고객 관리 컨텍스트와 상품 추천 컨텍스트가 Customer 도메인 객체를 공동 정의하여 사용하고, 해당 모델 변경 시 공동 리뷰 및 버전 호환성 테스트를 거쳐 릴리즈를 조율함.

• 코드 예시:

  1 2 3 4 5 6 7 8 9 10 11

  # shared_kernel/customer.py class Customer: def __init__(self, id, name, status): if not name: raise ValueError("Name cannot be empty") self.id = id self.name = name self.status = status def is_active(self): return self.status == "active"

  • 비즈니스 규칙 포함: 단순 데이터 모델이 아닌 도메인 객체
  • 검증 포함: 유효성 검사 로직 포함
  • 함수적 행위 포함: 모델의 행위적 책임 부여
  • → 이런 구조는 Shared Kernel 의 의미를 더 잘 드러냄

Separate Ways

• 활용 사례: 서로 다른 공급사의 ERP 및 CRM 시스템을 조직 내에서 독립적으로 운영. 고객 정보가 양 시스템에 중복 저장되지만, 각 시스템이 별도의 기능, 정책, 배포 주기를 가지므로 통합을 포기하고 각자 진화시킴.

• 사용 예시: 병원 시스템에서 예약은 프론트 데스크에서, 진료는 의료진이 사용하는 시스템에서 관리되며, 두 컨텍스트는 물리적/논리적으로 완전히 분리됨. 환자 정보는 각 시스템에서 개별 저장 및 운영되고, 데이터는 일치하지 않아도 무방한 구조로 설계됨.

• 코드 예시:

  1 2 3 4 5 6 7 8 9 10 11

  # 예약 시스템 - 예약 도메인 모델 (reservation_service/models.py) class Reservation: def __init__(self, patient_id, schedule_time): self.patient_id = patient_id self.schedule_time = schedule_time # 진료 시스템 - 진료 도메인 모델 (treatment_service/models.py) class Treatment: def __init__(self, patient_id, diagnosis): self.patient_id = patient_id self.diagnosis = diagnosis

  • 두 시스템은 파일/모듈 구조 자체가 다르며 독립적 저장소, 배포, 개발팀에 의해 관리됨
  • 참조나 연동 없이 자체 로직 기반 처리
  • 데이터 중복 허용, 일관성 보장 안 해도 되는 구조

Customer-Supplier

• 활용 사례: 주문 서비스가 결제 API 를 호출하거나, 사용자 인증 서비스가 다른 마이크로서비스에 인증 기능을 제공하는 경우처럼, Downstream 이 Upstream 의 안정된 계약 (API 명세) 에 의존하는 구조. 변경이 발생하면 하위 호환성 유지가 중요하며, 계약 테스트 및 API 버전 관리가 핵심.

• 사용 예시: 주문 생성 시 결제 API 호출은 반드시 사전에 합의된 API 명세 (OpenAPI 등) 에 기반하여 개발되며, 명세 변경 시 하위 시스템에 영향이 없도록 Pact 등을 통해 계약 테스트가 수행된다.

• 코드 예시:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  import requests class PaymentServiceClient: BASE_URL = "https://payment-service/api/v1" def __init__(self, token: str): self.headers = {"Authorization": f"Bearer {token}"} def pay_order(self, order_id: str, amount: float) -> dict: try: response = requests.post( f"{self.BASE_URL}/pay", headers=self.headers, json={"order_id": order_id, "amount": amount}, timeout=5 ) response.raise_for_status() return response.json() except requests.RequestException as e: # 실패 시 로깅 및 fallback 처리 raise RuntimeError(f"결제 API 호출 실패: {e}")

  • URI 버전 명시
  • 인증 토큰 처리
  • 예외 처리 및 안정성 확보
  • 향후 API 스펙 변경에 대비 가능

Conformist

• 활용 사례: 외부 결제 게이트웨이 (PG 사) 또는 OAuth 인증 시스템 (Google, Kakao 등) 과의 연동에서, 소비자는 제공자의 API/데이터 구조를 그대로 수용한다. 이 경우, 공급자의 변경에 대해 협상 없이 그대로 따르게 되며, Downstream 은 Upstream 에 완전히 종속된다.

• 사용 예시: 외부 API 에서 응답받은 status, transaction_id 구조를 별도의 변환 없이 서비스 로직과 UI 로직에 그대로 사용. API 명세가 바뀌면 Downstream 전체가 영향을 받음.

• 코드 예시:

  1 2 3 4 5 6 7 8 9 10 11 12

  # 외부 결제 서비스 API 응답 (Upstream 모델 그대로 사용) class PaymentResponse: def __init__(self, status, transaction_id): self.status = status self.transaction_id = transaction_id # 내부 주문 도메인에서 직접 사용 (변환 계층 없이) def handle_payment_result(response: PaymentResponse): if response.status == "SUCCESS": print(f"거래 완료: {response.transaction_id}") else: print("결제 실패")

  • PaymentResponse 는 외부 API 명세 기반 모델
  • handle_payment_result() 함수는 이를 도메인 내부에서 직접 사용
  • 변환 계층 (ACL, Adapter 등) 없이 그대로 사용하는 구조 → Conformist 패턴의 본질

Anti-Corruption Layer (ACL)

• 활용 사례: 레거시 시스템 또는 외부 API 의 도메인 모델이 내부 설계와 맞지 않거나, 통합 시 내부 도메인의 규칙을 침범할 우려가 있을 때, 중간 계층에서 Adapter 또는 Translator 를 통해 외부 모델을 내부 도메인 모델로 변환. 이를 통해 결합도를 낮추고 변경에 대한 격리를 확보함.

• 사용 예시: 외부 주문 시스템에서 수신된 LegacyOrder 를 내부 Order 도메인 모델로 변환하는 LegacyOrderAdapter 를 구현. 외부 시스템 변경 시에도 Adapter 만 수정하면 되고, 내부 도메인 로직은 영향을 받지 않음.

• **코드 예시 **:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

  # 외부 시스템에서 받은 객체 (레거시 모델) class LegacyOrder: def __init__(self, order_id, customer_name, item_list): self.order_id = order_id self.customer_name = customer_name self.item_list = item_list # 문자열 목록 (ex: ["item1:2", "item2:1"]) # 내부 도메인 모델 class OrderItem: def __init__(self, name, quantity): self.name = name self.quantity = quantity class Order: def __init__(self, id, customer, items): self.id = id self.customer = customer self.items = items # List[OrderItem] # ACL - Adapter class LegacyOrderAdapter: @staticmethod def convert(legacy_order: LegacyOrder) -> Order: items = [] for item_str in legacy_order.item_list: name, qty = item_str.split(":") items.append(OrderItem(name=name.strip(), quantity=int(qty))) return Order( id=legacy_order.order_id, customer=legacy_order.customer_name, items=items )

  • 외부의 레거시 모델 LegacyOrder 는 내부에서 직접 사용하지 않음
  • 내부 도메인 모델 Order, OrderItem 은 자체 규칙에 따라 정의됨
  • LegacyOrderAdapter 는 외부→내부 번역 계층이며, ACL 의 구현체

요약

• OHS, Published Language 는 Upstream 주도형 패턴
• Customer-Supplier, Conformist, ACL 은 Downstream 통합 전략
• Partnership, Shared Kernel 은 Midway 협력 패턴
• Separate Ways 는 전략적 비통합을 의도한 극단적 분리 전략

구현 기법

구현 기법 예시

드론 배송 시스템을 실제 사례로 활용한 DDD 구현 기법 예시

Event Storming: 드론 배송 프로세스

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# 📌 Event Storming 워크숍 문서

## 📍 시나리오 제목: 드론 배송 주문 처리

### 🎯 목적
- 드론 배송 도메인 흐름 파악
- Bounded Context 후보 식별

---

### 🟠 Domain Events
| 순번 | 이벤트명             | 트리거 액션               | 설명                                |
|------|----------------------|----------------------------|-------------------------------------|
| 1    | 주문 생성됨          | 고객이 상품을 주문         | 주문 정보가 시스템에 등록됨           |
| 2    | 결제 처리됨          | 주문 완료 시               | PG사 연동을 통한 결제 성공 처리        |
| 3    | 드론 배송 예약됨      | 결제 완료 후               | 드론 배송 일정이 예약됨               |
| 4    | 드론 출발함           | 배송 시간이 도래           | 드론이 창고에서 출발함                 |
| 5    | 배송 완료됨          | 드론이 목적지에 도착        | 고객에게 상품 전달 완료됨              |

---

### 🟢 Commands
| Command 이름      | 발행 주체           | 결과 이벤트           |
|-------------------|----------------------|------------------------|
| PlaceOrder        | 고객                 | 주문 생성됨           |
| ProcessPayment    | 주문 서비스          | 결제 처리됨           |
| ScheduleDelivery  | 배송 스케줄러        | 드론 배송 예약됨       |

---

### 🟣 Aggregates
- `Order`
- `Payment`
- `Delivery`

---

### 🔗 External Systems
- PG사 결제 시스템
- 드론 제어 시스템

Domain Storytelling: 드론 배송 시나리오

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# 📌 Domain Storytelling 문서

## 🎯 시나리오: 드론 기반 배송 주문 흐름

---

### 🧑 Actors
- 고객
- 주문 시스템
- 결제 시스템
- 배송 스케줄러
- 드론 운용 시스템

---

### 📖 시퀀스

1. 고객이 앱에서 상품을 주문한다.
2. 주문 시스템이 주문을 생성한다.
3. 주문 시스템이 결제를 요청한다.
4. 결제 시스템이 결제를 승인한다.
5. 배송 스케줄러가 드론 배송을 예약한다.
6. 배송 시간이 도래하면 드론 운용 시스템이 드론을 출발시킨다.
7. 드론이 고객에게 배송을 완료한다.

---

### 📦 Work Objects
- 주문 정보 (Order)
- 결제 요청 (Payment Request)
- 배송 스케줄 (Delivery Schedule)
- 드론 위치 정보 (Drone GPS)

Bounded Context Canvas: 배송 관리 (Delivery Management)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 📘 Bounded Context Canvas

## 🌐 Bounded Context 이름: 배송 관리 (Delivery Management)

---

### 🎯 Purpose
- 드론을 통한 배송 수행 및 상태 관리

---

### 🧭 Business Model
- 배송 요청은 주문 완료 후 생성됨
- 배송 상태는 '예약됨 → 출발함 → 배송 완료됨' 등으로 전이됨
- 드론 ID, 배송 시간, 위치 정보 포함

---

### 🔤 Ubiquitous Language
| 용어         | 정의                                    |
|--------------|-----------------------------------------|
| 배송 예약됨   | 드론이 특정 시간에 출발하도록 지정됨         |
| 드론 출발함   | 실제 배송이 시작됨                        |
| 배송 완료됨   | 고객 위치에 드론이 도착, 상품 전달됨         |

---

### 🔁 External Interfaces
| 시스템명             | 방식     | 설명                        |
|----------------------|----------|-----------------------------|
| 주문 시스템           | REST     | 주문 ID 기반 배송 예약 요청     |
| 드론 운용 시스템       | gRPC     | 드론 이동 명령 및 위치 조회     |
| 모니터링 시스템       | Kafka    | 배송 상태 실시간 스트림 전달    |

Context Mapping Workshop: 전체 드론 배송 시스템

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# 🧭 Context Mapping Workshop 결과

## 🧩 참여 Bounded Context 목록

| 이름                | 주요 기능                         | 담당 팀       |
|---------------------|----------------------------------|--------------|
| 주문 관리(Order)     | 상품 주문 생성 및 상태 관리             | 주문팀 김XX   |
| 결제(Payment)       | 결제 요청 및 응답 처리                | 결제팀 이XX   |
| 배송 관리(Delivery)  | 드론 예약 및 배송 상태 관리            | 물류팀 박XX   |
| 드론 운용(Drone Ops) | 드론 이동 제어, 상태 확인              | 운영팀 최XX   |

---

## 🔄 관계 및 통합 패턴

| Source BC      | Target BC         | 관계 유형             | 통합 패턴             |
|----------------|-------------------|------------------------|------------------------|
| 주문 관리        | 결제               | Customer-Supplier       | REST API               |
| 주문 관리        | 배송 관리          | Customer-Supplier       | REST API               |
| 배송 관리        | 드론 운용          | Anti-Corruption Layer   | gRPC + Adapter 패턴     |
| 배송 관리        | 모니터링 시스템     | Upstream Event Publisher| Kafka 메시지 발행       |

---

## 🧠 논의 결과 및 전략
- 드론 운용 시스템은 외부 시스템에 가까우므로 ACL 사용
- 이벤트는 Kafka 기반으로 발행하여 실시간 추적 가능하게 구성

장점

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

분류 기준에 따른 종류 및 유형

실무 사용 예시

• Bounded Context는 거의 모든 카테고리에 걸쳐 핵심 기반으로 사용됨.
• Context Map은 서비스 정의, 팀 정렬, 배포 전략 등 다방면에서 활용됨.
• Event Storming은 설계 초기와 반복적 개선 과정에서 강력한 도구로 작동함.

활용 사례

사례 1: 전자상거래 플랫폼 구축 사례

시스템 구성:

• Order Management Context: 주문 처리 및 상태 관리
• Inventory Context: 재고 관리 및 가용성 확인
• Payment Context: 결제 처리 및 검증
• Shipping Context: 배송 관리 및 추적
• Customer Context: 고객 정보 및 프로필 관리

시스템 구성 다이어그램:

graph TB
    subgraph "Customer Experience"
        Web[Web Frontend]
        Mobile[Mobile App]
    end
    
    subgraph "Core Business Contexts"
        OM[Order Management]
        INV[Inventory]
        PAY[Payment]
        SHIP[Shipping]
        CUST[Customer]
    end
    
    subgraph "Supporting Contexts"
        NOT[Notification]
        REP[Reporting]
        AUTH[Authentication]
    end
    
    Web --> OM
    Mobile --> OM
    OM --> INV
    OM --> PAY
    OM --> SHIP
    OM --> CUST
    OM --> NOT
    
    INV -.->|Events| REP
    PAY -.->|Events| REP
    SHIP -.->|Events| REP

활용 워크플로:

1. 도메인 분석 단계

   • EventStorming 을 통한 주문 프로세스 모델링
   • 도메인 전문가와 핵심 이벤트 식별
   • 하위 도메인 분류 (Core: 주문, Supporting: 재고/배송, Generic: 인증)

2. Bounded Context 설계

   • 각 컨텍스트의 Ubiquitous Language 정의
   • 컨텍스트 간 통합 패턴 선택
   • Anti-Corruption Layer 설계

3. Context Mapping

   • Order → Inventory: Customer-Supplier 관계
   • Order → Payment: Partnership 관계
   • Order → Shipping: Customer-Supplier 관계

Strategic Design 의 역할:

• 복잡성 관리: 대규모 전자상거래 도메인을 관리 가능한 컨텍스트로 분해
• 팀 자율성: 각 컨텍스트별 독립적인 개발팀 구성
• 비즈니스 정렬: Core Domain(주문 처리) 에 최고 품질 팀 배정
• 변화 대응: 새로운 비즈니스 요구사항에 대한 영향 범위 제한

사례 2: 이커머스 주문처리 시스템

시스템 구성 및 워크플로우:

graph LR
  subgraph Catalog_BC
    CatalogAPI
  end
  subgraph Order_BC
    OrderAPI
  end
  subgraph Payment_BC
    PaymentAPI
  end
  Catalog_BC -->|ACL| Order_BC
  Order_BC -->|Customer–Supplier| Payment_BC

Workflow

1. 카탈로그 BC: 제품 조회
2. 주문 BC: 주문 생성 시 카탈로그에서 ACL 통해 데이터 조회
3. 결제 BC: 주문 BC 가 고객으로서 결제 요청
4. BC 간 명확한 경계와 계약 기반 통합

구현 예시

Strategic Design 패턴을 활용한 전자상거래 시스템 구현

1. Bounded Context: Order Management 와 Inventory Management 로 명확히 구분
2. Ubiquitous Language: 각 컨텍스트에서 도메인 특화 용어 사용
3. Domain Events: 컨텍스트 간 느슨한 결합 통신
4. Context Integration: Customer-Supplier 패턴 구현
5. Anti-Corruption Layer: 외부 시스템과의 안전한 통합

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242

from abc import ABC, abstractmethod
from typing import List, Dict, Optional
from dataclasses import dataclass, field
from datetime import datetime
import uuid

# =============================================================================
# Domain Events (도메인 이벤트)
# =============================================================================

@dataclass
class DomainEvent:
    """도메인 이벤트 기본 클래스"""
    event_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    occurred_at: datetime = field(default_factory=datetime.now)
    
class OrderCreated(DomainEvent):
    """주문 생성 이벤트"""
    def __init__(self, order_id: str, customer_id: str, items: List[Dict]):
        super().__init__()
        self.order_id = order_id
        self.customer_id = customer_id
        self.items = items

class InventoryReserved(DomainEvent):
    """재고 예약 이벤트"""
    def __init__(self, order_id: str, product_id: str, quantity: int):
        super().__init__()
        self.order_id = order_id
        self.product_id = product_id
        self.quantity = quantity

# =============================================================================
# Bounded Context: Order Management (주문 관리)
# =============================================================================

class OrderManagementContext:
    """
    주문 관리 Bounded Context
    Ubiquitous Language: Order, Customer, Product, OrderItem
    """
    
    def __init__(self):
        self.orders: Dict[str, 'Order'] = {}
        self.event_publisher = EventPublisher()
    
    def create_order(self, customer_id: str, items: List[Dict]) -> str:
        """주문 생성 - 핵심 비즈니스 로직"""
        order_id = str(uuid.uuid4())
        
        # Ubiquitous Language 사용: Order Domain Model
        order = Order(
            order_id=order_id,
            customer_id=customer_id,
            items=[OrderItem(**item) for item in items],
            status=OrderStatus.PENDING
        )
        
        self.orders[order_id] = order
        
        # Domain Event 발행
        event = OrderCreated(order_id, customer_id, items)
        self.event_publisher.publish(event)
        
        return order_id
    
    def get_order(self, order_id: str) -> Optional['Order']:
        """주문 조회"""
        return self.orders.get(order_id)

@dataclass
class Order:
    """주문 Aggregate Root"""
    order_id: str
    customer_id: str
    items: List['OrderItem']
    status: 'OrderStatus'
    created_at: datetime = field(default_factory=datetime.now)

@dataclass  
class OrderItem:
    """주문 항목 Value Object"""
    product_id: str
    quantity: int
    price: float

class OrderStatus:
    """주문 상태 Value Object"""
    PENDING = "PENDING"
    CONFIRMED = "CONFIRMED"
    SHIPPED = "SHIPPED"
    DELIVERED = "DELIVERED"

# =============================================================================
# Bounded Context: Inventory Management (재고 관리)
# =============================================================================

class InventoryManagementContext:
    """
    재고 관리 Bounded Context
    Ubiquitous Language: Product, Stock, Availability
    """
    
    def __init__(self):
        self.inventory: Dict[str, 'ProductStock'] = {}
        self.event_publisher = EventPublisher()
        
        # 샘플 데이터
        self.inventory = {
            "product-1": ProductStock("product-1", 100),
            "product-2": ProductStock("product-2", 50)
        }
    
    def check_availability(self, product_id: str, quantity: int) -> bool:
        """재고 가용성 확인"""
        stock = self.inventory.get(product_id)
        return stock is not None and stock.available_quantity >= quantity
    
    def reserve_inventory(self, order_id: str, product_id: str, quantity: int) -> bool:
        """재고 예약 - Anti-Corruption Layer 역할"""
        if self.check_availability(product_id, quantity):
            stock = self.inventory[product_id]
            stock.reserve(quantity)
            
            # Domain Event 발행
            event = InventoryReserved(order_id, product_id, quantity)
            self.event_publisher.publish(event)
            return True
        return False

@dataclass
class ProductStock:
    """상품 재고 Aggregate"""
    product_id: str
    available_quantity: int
    reserved_quantity: int = 0
    
    def reserve(self, quantity: int):
        """재고 예약"""
        if self.available_quantity >= quantity:
            self.available_quantity -= quantity
            self.reserved_quantity += quantity
        else:
            raise ValueError("재고 부족")

# =============================================================================
# Context Integration: Event Publisher (컨텍스트 통합)
# =============================================================================

class EventPublisher:
    """
    Context Map 구현: Event-driven integration
    컨텍스트 간 느슨한 결합 통신
    """
    
    def __init__(self):
        self.subscribers: Dict[type, List] = {}
    
    def subscribe(self, event_type: type, handler):
        """이벤트 구독 등록"""
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(handler)
    
    def publish(self, event: DomainEvent):
        """이벤트 발행"""
        event_type = type(event)
        if event_type in self.subscribers:
            for handler in self.subscribers[event_type]:
                handler(event)

# =============================================================================
# Integration Patterns: Order-Inventory Context Mapping
# =============================================================================

class OrderInventoryIntegration:
    """
    Order Context와 Inventory Context 간 통합
    Pattern: Customer-Supplier (Order가 Customer, Inventory가 Supplier)
    """
    
    def __init__(self, order_context: OrderManagementContext, 
                 inventory_context: InventoryManagementContext):
        self.order_context = order_context
        self.inventory_context = inventory_context
        
        # Event 기반 통합 설정
        order_context.event_publisher.subscribe(OrderCreated, self.handle_order_created)
    
    def handle_order_created(self, event: OrderCreated):
        """주문 생성 시 재고 예약 처리"""
        print(f"주문 생성됨: {event.order_id}")
        
        for item in event.items:
            success = self.inventory_context.reserve_inventory(
                event.order_id, 
                item['product_id'], 
                item['quantity']
            )
            
            if success:
                print(f"재고 예약 성공: {item['product_id']} x {item['quantity']}")
            else:
                print(f"재고 부족: {item['product_id']}")

# =============================================================================
# Strategic Design 시나리오 실행
# =============================================================================

def demonstrate_strategic_design():
    """Strategic Design 패턴 실증"""
    
    print("=== Strategic Design in DDD 실증 ===\n")
    
    # 1. Bounded Context 생성
    order_context = OrderManagementContext()
    inventory_context = InventoryManagementContext()
    
    # 2. Context Integration 설정
    integration = OrderInventoryIntegration(order_context, inventory_context)
    
    # 3. 비즈니스 시나리오 실행
    print("1. 고객 주문 생성")
    order_items = [
        {"product_id": "product-1", "quantity": 2, "price": 29.99},
        {"product_id": "product-2", "quantity": 1, "price": 49.99}
    ]
    
    order_id = order_context.create_order("customer-123", order_items)
    print(f"주문 ID: {order_id}\n")
    
    # 4. Context Map을 통한 상호작용 확인
    print("2. 컨텍스트 간 상호작용 결과")
    order = order_context.get_order(order_id)
    print(f"주문 상태: {order.status}")
    
    print(f"재고 현황:")
    for product_id, stock in inventory_context.inventory.items():
        print(f"  {product_id}: 가용 {stock.available_quantity}, 예약 {stock.reserved_quantity}")

if __name__ == "__main__":
    demonstrate_strategic_design()

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

주제와 관련하여 반드시 학습해야할 내용

용어 정리

참고 및 출처

핵심 문헌

• Domain-Driven Design: Tackling Complexity in the Heart of Software–Eric Evans 의 DDD 원서
• Implementing Domain-Driven Design–Vaughn Vernon 의 실무 지침서
• Learning Domain-Driven Design–Vlad Khononov 저, O’Reilly 출판의 입문서

온라인 리소스

개념 및 설계 설명

• Domain-Driven Design (Bliki)–Martin Fowler 의 설명
• Domain-Driven Design (Wikipedia)–위키백과 개요
• Strategic Design in DDD–DevIQ 의 전략 설계 설명
• Domain-Driven Design (DDD): Strategic Design Explained–Medium 아티클

전략적 설계 심화

• Strategic Domain-Driven Design with Context Mapping–InfoQ 의 컨텍스트 매핑 설명
• DDD Part 1: Strategic Domain‑Driven Design–Vaadin 블로그
• A Hitchhiker’s Guide to Strategic Design–HYR.MN 블로그 가이드

실무 도구 및 플랫폼

• Context Mapper–Context Map 설계 및 시각화 도구
• EventStorming–Alberto Brandolini 의 협업적 도메인 모델링
• Domain Storytelling–스토리 기반 도메인 설계 방법론
• Bounded Context Canvas–Nick Tune 이 설계한 캔버스 템플릿

커뮤니티 및 교육

• Domain-Driven Design Community–DDD 공식 커뮤니티
• DDD Academy–교육 자료 및 과정
• Virtual DDD–온라인 워크숍, 세미나 커뮤니티
• Awesome DDD–GitHub 기반 DDD 자료 모음

기술 블로그 및 사례 연구

• Domain Driven Design in 10 Minutes (Part One)–ThoughtWorks 블로그
• Using Tactical DDD to Design Microservices–Microsoft Azure Architecture Center
• Domain-Driven Design Fundamentals – Redis–Redis 공식 문서