Domain-Driven Design

Domain-Driven Design

DDD 는 에릭 에반스 (Eric Evans) 가 2003 년 제안한 방법론으로, Domain-Driven Design(DDD) 는 소프트웨어 개발에서 도메인 (비즈니스 영역) 의 복잡성을 효과적으로 해결하기 위해 도메인 모델링을 중심에 두는 접근법이다.
전략적 설계에서는 시스템을 Bounded Context, Subdomain, Context Map으로 구획화하며, 전술적 설계에서는 Entity, Value Object, Aggregate, Repository, Domain Event, Factory, Service 구조를 코드에 구현한다. 핵심은 도메인 전문가와 개발자가 유비쿼터스 언어를 통해 소통하며, 바운디드 컨텍스트별로 명확한 모델을 구축하고, 엔티티, 값 객체, 애그리게이트, 도메인 서비스, 도메인 이벤트 등 다양한 전술적 패턴을 적용하는 것이다.
DDD 는 복잡한 비즈니스 로직을 효과적으로 관리하고, 유지보수성과 확장성이 뛰어난 시스템을 구축하는 데 매우 유용하다.
현재 마이크로서비스 아키텍처, CQRS (Command Query Responsibility Segregation), 이벤트 소싱 (Event Sourcing) 과 함께 사용되어 현대적인 분산 시스템 구축에 핵심적으로 활용되고 있다.

핵심 개념

Domain-Driven Design(DDD) 의 핵심 개념은 전략적 설계 (Strategic Design) 와 전술적 설계 (Tactical Design) 의 두 축을 기반으로 구성된다.

전략적 설계 (Strategic Design)

도메인 전체를 비즈니스 관점에서 논리적으로 분해하고, 시스템을 경계 (Context) 단위로 나누는 고수준 설계 전략.

전술적 설계 (Tactical Design)

각 Bounded Context 내부에서 도메인 모델을 어떻게 설계하고 구현할지에 관한 세부 설계 기법.

아키텍처 및 구현 관련 요소

실무 적용 도구 및 협업 기법

배경

DDD 는 2003 년 Eric Evans 의 저서 “Domain-Driven Design: Tackling Complexity in the Heart of Software” 를 통해 소개되었다. 복잡한 소프트웨어 개발에서 기술적 측면보다는 비즈니스 도메인에 집중해야 한다는 철학에서 출발했다.
DDD 는 기존의 데이터 중심 설계 (Data-Driven Design) 의 한계를 극복하기 위해 등장했다.

전통적인 소프트웨어 개발에서는 다음과 같은 문제점들이 있었다:

• 비즈니스 도메인에 대한 이해 부족: 기술적 구현에만 집중하여 실제 비즈니스 요구사항과 괴리
• 도메인 전문가와 개발자 간 소통 단절: 서로 다른 언어와 관점으로 인한 오해
• 복잡성 관리 실패: 시스템이 커질수록 유지보수가 어려워지는 구조
• 변화에 대한 취약성: 비즈니스 변화에 유연하게 대응하지 못하는 경직된 설계

목적 및 필요성

주요 목적

1. 비즈니스 - 기술 격차 해소: 비즈니스와 소프트웨어 개발 간의 격차를 줄이고 기술 팀과 도메인 전문가 간의 명확한 소통 촉진
2. 복잡성 관리: 복잡한 비즈니스 로직을 캡슐화하는 도메인 모델을 통해 비즈니스 현실과 코드 간의 격차 해소
3. 시스템 모듈화: 대규모 도메인을 여러 Bounded Context 로 분할하여 명시적 관계 설정

필요성

• 레거시 시스템의 한계: 단일 통합 모델의 한계로 인한 Big Ball of Mud 아키텍처 방지
• 마이크로서비스 경계 정의: 마이크로서비스 아키텍처에서 서비스 경계를 정의하는 지침 제공
• 지속적인 진화: 변화하는 비즈니스 도메인에 맞춰 소프트웨어가 진화할 수 있는 구조 제공

주요 기능 및 역할

• 도메인 모델링: 비즈니스 로직과 규칙을 객체로 모델링
• 바운디드 컨텍스트 설계: 도메인별 경계 설정 및 독립적 개발
• 유비쿼터스 언어 적용: 공통 언어로 커뮤니케이션
• 애그리게이트 및 엔티티 설계: 비즈니스 규칙 중심의 객체 설계
• 도메인 서비스 및 리포지토리 구현: 비즈니스 로직과 데이터 접근 분리

전략적 설계 (Strategic Design)

• 도메인 분할: 큰 도메인을 하위 도메인으로 나누어 관리
• 바운디드 컨텍스트 식별: 모델의 일관성이 유지되는 경계 정의
• 컨텍스트 매핑: 바운디드 컨텍스트 간의 관계와 통합 방식 설계

전술적 설계 (Tactical Design)

• 도메인 모델링: 엔티티, 밸류 오브젝트, 애그리거트 설계
• 비즈니스 로직 구현: 도메인 서비스와 도메인 이벤트 활용
• 아키텍처 패턴 적용: 레이어드, 헥사고날 아키텍처 구현

특징

핵심 특징

1. 도메인 중심성: 비즈니스 도메인이 설계의 중심
2. 협업 지향: 도메인 전문가와 개발자의 긴밀한 협력
3. 진화적 설계: 지속적인 학습과 개선을 통한 모델 발전
4. 명시적 모델링: 암묵적 지식을 명시적 코드로 표현

구별되는 특징

• 유비쿼터스 언어: 모든 의사소통에서 동일한 용어 사용
• 바운디드 컨텍스트: 모델의 적용 범위를 명확히 제한
• 애그리거트: 일관성 경계를 명확히 정의
• 이벤트 중심 사고: 비즈니스 이벤트를 중심으로 모델링

핵심 원칙

DDD 의 핵심 원칙은 도메인 중심의 설계와 유비쿼터스 언어의 사용이다. 도메인 전문가와 개발자가 협업하여 도메인 모델을 구축하고, 이를 소프트웨어에 반영한다. 또한, 바운디드 컨텍스트를 정의하여 도메인 모델의 적용 범위를 명확히 한다.

DDD 의 3 가지 핵심 원칙

1. Focus on the Core Domain (핵심 도메인에 집중)

   • 비즈니스 경쟁 우위를 제공하는 핵심 영역에 집중
   • 제한된 자원을 가장 중요한 부분에 투자

2. Explore Models in Collaboration (협력을 통한 모델 탐구)

   • 도메인 전문가와 개발자의 지속적 협력
   • 공동 모델링을 통한 깊은 도메인 이해

3. Speak Ubiquitous Language (유비쿼터스 언어 사용)

   • 모든 이해관계자가 동일한 언어 사용
   • 코드와 대화에서 일관된 용어 유지

graph TD
    A[도메인 전문가] --> B[유비쿼터스 언어]
    C[개발자] --> B
    D[테스터] --> B
    E[비즈니스 분석가] --> B
    
    B --> F[코드]
    B --> G[문서]
    B --> H[대화]
    B --> I[테스트]

설계 원칙

1. Model-Driven Design: 모델과 구현의 긴밀한 연결
2. Hands-On Modelers: 모델러가 직접 코드 작성 참여
3. Refactoring Toward Deeper Insight: 지속적 리팩토링을 통한 깊은 통찰

graph LR
    A[도메인 모델] <--> B[코드 구현]
    B <--> C[대화와 문서]
    C <--> A
    
    A -.-> D[지속적 리팩토링]
    D -.-> A

핵심 개념:

• 도메인 모델과 코드가 긴밀하게 연결
• 모델의 변화가 즉시 코드에 반영
• 지속적인 리팩토링을 통한 모델 개선

전략적 - 전술적 설계 분리

• 전략적 설계: 바운디드 컨텍스트, 유비쿼터스 언어, 컨텍스트 맵 등 시스템의 큰 구조를 정의한다.
• 전술적 설계: 엔티티, 값 객체, 애그리게이트, 도메인 서비스, 이벤트, 리포지토리 등 실질적 코드 구조를 설계한다.

graph LR
    A[Strategic Design] --> B[Tactical Design]
    
    subgraph Strategic
        C[Bounded Context]
        D[Context Map]
        E[Subdomain]
    end
    
    subgraph Tactical
        F[Aggregate]
        G[Entity]
        H[Value Object]
        I[Repository]
    end
    
    A --> Strategic
    B --> Tactical

DDD 개발 프로세스

sequenceDiagram
    participant DE as 도메인 전문가
    participant DEV as 개발자
    participant MODEL as 도메인 모델
    participant CODE as 코드
    
    DE->>DEV: 도메인 지식 공유
    DEV->>MODEL: 초기 모델링
    MODEL->>CODE: 코드 구현
    CODE->>DEV: 구현을 통한 학습
    DEV->>DE: 질문과 확인
    DE->>DEV: 피드백 제공
    DEV->>MODEL: 모델 개선
    MODEL->>CODE: 리팩토링
    
    Note over DE,CODE: 지속적인 협력과 개선

1. 도메인 지식 공유 (DE ➡ DEV)
   도메인 전문가 (Subject Matter Expert) 는 개발자에게 비즈니스의 규칙, 용어, 흐름 등 도메인 지식을 전달한다.
   이는 유비쿼터스 언어 (Ubiquitous Language) 의 형성 및 모델링의 시작점이다.

2. 초기 모델링 (DEV ➡ MODEL)
   개발자는 공유받은 도메인 지식을 바탕으로 개념 모델을 만듭니다. 이 모델은 엔티티, 값 객체, 애그리게이트 등을 포함한다.

3. 코드 구현 (MODEL ➡ CODE)
   모델링된 구조를 바탕으로 실제 코드로 구현한다. 이 때, 애플리케이션 레이어, 도메인 레이어, 인프라스트럭처 레이어 등 계층적 아키텍처 설계를 따르게 된다.

4. 구현을 통한 학습 (CODE ➡ DEV)
   코드를 작성하고 테스트하는 과정에서 개발자는 도메인에 대한 새로운 이해를 얻게 되고, 때로는 기존 이해에 오류가 있었음을 발견한다.

5. 질문과 확인 (DEV ➡ DE)
   개발자는 도메인 전문가에게 다시 질문하거나 모델에 대한 확인을 요청한다. 이 과정은 도메인에 대한 해석 오류 방지를 위한 중요한 피드백 루프이다.

6. 피드백 제공 (DE ➡ DEV)
   도메인 전문가는 잘못된 부분을 바로잡거나, 새로운 도메인 규칙 또는 예외 상황을 공유한다.

7. 모델 개선 (DEV ➡ MODEL)
   피드백을 반영해 도메인 모델을 재구성하거나 수정한다. 이는 종종 이벤트 스토밍, 컨텍스트 매핑 등 협업 기법을 통해 이루어진다.

8. 리팩토링 (MODEL ➡ CODE)
   개선된 도메인 모델에 따라 코드를 리팩토링한다. 이 과정은 기술 부채를 줄이고, 도메인 변경에 유연한 구조를 만드는데 핵심이다.

전략적 설계 (Strategic Design)

도메인 전체를 비즈니스 관점에서 논리적으로 분해하고, 시스템을 경계 (Context) 단위로 나누는 고수준 설계 전략.

주요 목적

• 도메인을 의미 있는 단위로 분리
• 팀 간 책임 범위 분할
• 모델 간 통합 관계 정의

핵심 구성요소

예시:

• Core Subdomain: 결제 시스템
• Bounded Context: Payment, Invoice
• Context Map: Payment ↔ Invoice 는 Customer-Supplier 관계로 구성

Subdomain 의 세 가지 분류

바운디드 컨텍스트 간 통합 패턴

graph TD
    subgraph BoundedContextA
        A1[Entity]
        A2[Value Object]
        A3[Aggregate Root]
        A4[Domain Service]
        A5[Repository]
        A6[Domain Event]
        A1 --> A3
        A2 --> A3
        A3 --> A4
        A3 --> A5
        A4 --> A6
    end
    subgraph BoundedContextB
        B1[Entity]
        B2[Value Object]
        B3[Aggregate Root]
        B1 --> B3
        B2 --> B3
    end
    A3 -. Context Map .-> B3

Bounded Context 간의 관계와 내부 구조를 시각화한 것으로, 각 컨텍스트는 독립적으로 도메인을 모델링하며, 상호 통합 시 Context Map을 통해 연결된다.

Bounded Context A 의 구성:

→ 각 요소는 다음과 같이 연결된다:

• Entity 와 Value Object 는 Aggregate Root 와 연결.
• Aggregate Root 는 비즈니스 로직 (Domain Service), 영속화 (Repository) 와 연결됨.
• Domain Service 에서 중요한 상태 변화가 발생하면 Domain Event 가 발행됨.

Bounded Context B 의 구성:

• Entity (B1) 와 Value Object (B2) 는
  → Aggregate Root (B3) 아래에서 함께 모델링되어 있음.

→ 이는 하나의 다른 서브 도메인 또는 마이크로서비스가 독립적으로 설계된 구조를 보여준다.

Context Map 에 의한 연결

• A3 -. Context Map.-> B3 는 Bounded Context A 의 Aggregate Root 와 B 의 Aggregate Root 가 연결됨을 의미한다.
• 이 연결은 Context Map의 일종으로, 다음과 같은 전략들이 있을 수 있다:

→ 위 다이어그램에서는 컨텍스트 간 직접 연결된 점선이 있으므로, 일반적으로 ACL 또는 Conformist 전략을 사용하는 경우에 해당할 수 있다.

전술적 설계 (Tactical Design)

각 Bounded Context 내부에서 도메인 모델을 어떻게 설계하고 구현할지에 관한 세부 설계 기법.

주요 목적:

• 도메인 모델을 코드로 명확하게 구현
• 복잡한 도메인 로직을 모듈화
• 시스템 복잡성 감소 및 유지보수성 향상

핵심 구성요소

Domain-Driven Design 통합 아키텍처

graph TD
  %% SYSTEM 구성
  A[System] --> B[Subdomains]
  B --> C1[Core Subdomain]
  B --> C2[Supporting Subdomain]
  B --> C3[Generic Subdomain]

  %% Bounded Context와 Subdomain 연결
  C1 --> BC1[Bounded Context A]
  C2 --> BC2[Bounded Context B]
  C3 --> BC3[Bounded Context C]

  %% Context Map 관계
  subgraph ContextMap[Context Map]
    BC1 <-->|Shared Kernel| BC2
    BC2 <-->|Customer-Supplier| BC3
    BC1 -.->|Anti-Corruption Layer| BC3
  end

  %% Bounded Context A 내부 계층 구조
  subgraph BoundedContextA
    direction TB
    UI[Presentation Layer]
    UI --> App[Application Layer]

    App --> AL1[Application Service]
    AL1 --> DL[Domain Layer]
    DL --> AR[Aggregate Root]
    AR --> E[Entity]
    AR --> V[Value Object]
    DL --> DS[Domain Service]
    DL --> DE[Domain Event]
    DL --> RI[Repository Interface]
    DL --> SP[Specification]
    DL --> F[Factory]

    App --> INF[Infrastructure Layer]
    INF --> RImpl[Repository Implementation]
    INF --> Adapter["External Adapter (API, Messaging)"]
    INF --> DB[(Database)]
  end

  %% 설명 연결 (선택)
  click ContextMap href "https://martinfowler.com/bliki/ContextMap.html" "Context Map 설명 보기"
  click B href "https://dddcommunity.org/library/" "Subdomain 설명 보기"

Domain-Driven Design 의 Layered Architecture

DDD 는 일반적으로 다음과 같은 4 계층 구조를 따른다:

1. 프레젠테이션 계층 (Presentation Layer)
2. 응용 계층 (Application Layer)
3. 도메인 계층 (Domain Layer)
4. 인프라스트럭처 계층 (Infrastructure Layer)
   이 구조를 통해 각 계층은 단일 책임을 가지며, 하위 계층에 대한 의존성만을 가진다.

도메인 계층 (Domain Layer)

Domain Layer는 DDD(도메인 주도 설계) 의 아키텍처 계층 중 하나로, 핵심 비즈니스 로직, 규칙, 정책, 제약을 코드로 명시적으로 구현하는 계층을 의미한다.
이 계층은 시스템이 해결하려는 " 도메인 문제 영역 " 의 본질을 표현하며, 기술적인 세부사항과는 철저히 분리되어야 한다.

역할과 특징:

주요 구성 요소:

전략적 설계 (Strategic Design) vs. 전술적 설계 (Tactical Design)

Strategic Design은 무엇을 왜 구축할지에 대한 비즈니스 도메인의 전체적인 구조와 경계를 정의하는 고수준 설계 접근법이며, Tactical Design은 어떻게 구현할지에 대한 도메인 모델의 구체적인 구현을 위한 저수준 패턴과 기법을 제공한다.

• 전략적 설계 (Strategic Design) 를 통해 무엇을 만들고 누구와 협업할지를 설계한다.
  • 도메인 구조 설계, 팀/시스템 분할, 경계 정의를 통해 시스템의 큰 그림을 설계한다.
• 전술적 설계 (Tactical Design) 를 통해 그것을 어떻게 구현할지 를 구체화해야 한다.
  • 각 경계 내에서 도메인 모델을 구현하고, 객체지향 패턴을 적용하여 비즈니스 로직을 실제 코드로 옮긴다.
• Context Map 과 Ubiquitous Language 는 전략적 + 전술적 설계 사이의 연결 고리 역할을 한다.

DDD 설계 접근 방식 비교

강점과 약점

강점

약점

시각적 개요 흐름

graph TD
  A[Strategic Design] --> B[Subdomain 분석]
  B --> C[Bounded Context 정의]
  C --> D[Context Map 설계]
  D --> E[Ubiquitous Language 정립]
  E --> F[Tactical Design 진입]
  F --> G[Entity/VO/Aggregate 설계]
  G --> H[Repository/Service 적용]
  H --> I[테스트 및 구현 반복]

DDD Strategic ↔ Tactical 설계

도메인 주도 설계 (DDD) 에서 전략적 설계와 전술적 설계 간의 복잡하고 상호의존적인 관계를 체계적으로 나타낸다.

다이어그램의 최상단에서 시작하는 비즈니스 도메인은 전략적 설계의 출발점이 되며, 여기서 핵심 도메인, 지원 도메인, 일반 도메인으로 세분화된 서브도메인들이 식별된다. 이러한 서브도메인들은 경계 컨텍스트로 구체화되며, 각 컨텍스트는 고유한 유비쿼터스 언어를 통해 일관된 모델을 형성한다. 컨텍스트 맵은 이러한 경계 컨텍스트들 간의 관계와 통합 패턴을 명시적으로 정의한다.

전략적 설계에서 정의된 경계 컨텍스트는 전술적 설계의 핵심 진입점이 된다. 전술적 설계에서는 애그리게이트 루트가 중심적 역할을 수행하며, 이를 통해 엔티티, 값 객체, 도메인 이벤트들이 일관성 있게 관리된다. 애그리게이트 외부에는 도메인 서비스, 저장소 인터페이스, 팩토리, 모듈, 명세 패턴 등이 위치하여 애그리게이트와 협력한다.

구현 과정에서 발견되는 모델의 복잡성이나 한계는 다시 경계 컨텍스트의 재정의나 유비쿼터스 언어의 정제로 이어진다. 이러한 반복적 개선 과정은 DDD 의 핵심 철학인 지속적인 학습과 진화를 구현한다.

구현 계층에서는 헥사고날 아키텍처 원칙에 따라 REST API/UI, 애플리케이션 계층, 도메인 모델 계층, 인프라스트럭처 계층이 명확히 분리된다. 도메인 모델 계층은 전술적 설계의 핵심 요소들을 포함하며, 애플리케이션 계층은 저장소 인터페이스를 통해 도메인과 인프라스트럭처를 연결한다.

컨텍스트 간 통합은 다양한 패턴을 통해 이루어지며, 도메인 이벤트는 컨텍스트 간 비동기 통신의 핵심 메커니즘으로 작동한다. 이를 통해 각 컨텍스트의 독립성을 유지하면서도 필요한 협력을 가능하게 한다.

graph TD
    %% 전략적 설계
    A[📌 비즈니스 도메인] --> B["🧠 전략적 설계 (Strategic Design)"]
    B --> C1[📂 Core/Supporting/Generic Subdomains]
    B --> C2[🔲 Bounded Contexts]
    B --> C3[🗺️ Context Map]
    B --> C4[🗣️ Ubiquitous Language]
    
    %% Strategic에서 Tactical로의 연결
    C2 --> D["🔧 전술적 설계 (Tactical Design)"]
    C4 -.-> D
    
    %% Tactical Design - Aggregate 중심 구조
    D --> E1[🧱 Aggregate Root]
    E1 --> E2[🧩 Entity]
    E1 --> E3[📦 Value Object]
    E1 --> E6[🧨 Domain Event]
    
    %% Aggregate 외부 패턴들
    D --> E4[⚙️ Domain Service]
    D --> E5[📂 Repository Interface]
    D --> E7[🏭 Factory]
    D --> E8[📁 Module]
    D --> E9[📐 Specification]
    
    %% Repository 관계
    E5 -.-> E1
    E7 -.-> E1
    
    %% Context 간 관계
    C2 -->|Integration Patterns| F1[🔁 ACL / OHS / Conformist]
    C2 -->|Partnership/Customer-Supplier| F2[⬆️⬇️ Context Relations]
    
    %% 구현 계층 구조 (Hexagonal Architecture)
    subgraph "Implementation Layers"
        REST[🌐 REST API / UI]
        APP[📱 Application Layer]
        DOM[🏗️ Domain Model Layer]
        INFRA[💽 Infrastructure Layer]
    end
    
    %% 계층 간 관계
    REST --> APP
    APP --> DOM
    APP --> E5
    INFRA --> E5
    
    %% Domain Model 내부 구조
    DOM --> E1
    DOM --> E4
    DOM --> E8
    
    %% 피드백 루프 (중요!)
    D -.->|"모델 개선 피드백"| C2
    D -.->|"언어 정제 피드백"| C4
    
    %% 이벤트 기반 통합
    E6 -.->|"Context 간 통신"| F1
    
    %% 스타일링
    classDef strategic fill:#e1f5fe
    classDef tactical fill:#f3e5f5
    classDef implementation fill:#e8f5e8
    classDef integration fill:#fff3e0
    
    class A,B,C1,C2,C3,C4 strategic
    class D,E1,E2,E3,E4,E5,E6,E7,E8,E9 tactical
    class REST,APP,DOM,INFRA implementation
    class F1,F2 integration

Strategic Design 구성 요소

Tactical Design 구성 요소

Tactical Design 관계 구조

Aggregate 중심 구조:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Aggregate Root (중심)
├── Entity (포함)
├── Value Object (포함)
└── Domain Event (발행)

외부 지원:
├── Repository (저장/조회)
├── Factory (생성)
├── Domain Service (조작)
└── Specification (규칙 검증)

계층별 책임 분할:

graph LR
    subgraph "Aggregate Boundary"
        AR[Aggregate Root]
        E[Entity]
        VO[Value Object]
        DE[Domain Event]
    end
    
    subgraph "Supporting Patterns"
        DS[Domain Service]
        R[Repository]
        F[Factory]
        S[Specification]
    end
    
    AR --> E
    AR --> VO
    AR --> DE
    DS -.-> AR
    R -.-> AR
    F -.-> AR
    S -.-> AR

Strategic-Tactical 상호작용 메커니즘

도메인 주도 설계 (DDD) 에서 Strategic Design 과 Tactical Design 의 관계는 서로 얽혀있으면서 지속적으로 상호작용하며 진화하는 구조이다.
전략적 설계부터 시작하여 전술적 설계를 따르며, 가장 큰 도메인 모델 설계의 깨달음과 돌파구는 전술적 설계 중에 일어날 가능성이 높고, 이는 다시 전략적 설계에 영향을 미치므로 이 과정을 반복한다.

하향식 영향 (Strategic → Tactical)

Strategic Design 에서 Tactical Design 으로의 정보 흐름은 변환 (Translation) 과정을 통해 이루어진다. Strategic Design 에서 Tactical Design 으로의 변환은 추상적인 비즈니스 개념을 구체적인 코드 구조로 번역하는 핵심 과정이다.

구체적 변환 매핑:

도메인 모델의 각 Bounded Context 에 대해 도메인을 모델링하는 엔티티, 값 객체 및 집합체를 식별하고 정의한다. 컨텍스트를 정의하는 경계 내에 포함된 도메인 모델을 구축하고 개선한다.

단계별 변환 과정

변환 단계:

1. 도메인 탐색 → Bounded Context 식별 → Aggregate 후보 발견
2. Ubiquitous Language → Entity/Value Object 명명 → 메서드 시그니처 정의
3. Context Map → Integration Pattern → Domain Event 설계
4. Subdomain 분류 → Module 구조 → Package/Namespace 조직화

1 단계: 도메인 탐색 → Bounded Context 식별 → Aggregate 후보 발견

무엇을 만들 것인가? 에서 어떻게 나눌 것인가? 로의 변환

핵심 활동:

• 도메인 탐색 (Domain Exploration): 비즈니스 프로세스와 규칙 이해
• Bounded Context 식별: 일관된 모델 경계 정의
• Aggregate 후보 발견: 트랜잭션 일관성 단위 식별

입력물 (Input)

출력물 (Output)

핵심 의사결정:

• 컨텍스트 경계: 어디서 모델을 분리할 것인가?
• Aggregate 크기: 어떤 객체들을 함께 묶을 것인가?
• 일관성 요구사항: 어떤 데이터가 함께 변경되어야 하는가?

2 단계: Ubiquitous Language → Entity/Value Object 명명 → 메서드 시그니처 정의

비즈니스 용어를 코드 요소로 직접 번역하는 단계

핵심 활동:

• Ubiquitous Language 적용: 비즈니스 용어를 클래스/메서드명으로 변환
• Entity/Value Object 구분: 식별자 유무에 따른 객체 분류
• 메서드 시그니처 정의: 비즈니스 행동을 메서드로 구체화

입력물 (Input):

출력물 (Output):

핵심 의사결정:

• Entity vs Value Object: 식별자가 필요한가?
• 메서드 명명: 비즈니스 용어를 어떻게 반영할 것인가?
• 매개변수 설계: 어떤 정보가 필요한가?

3 단계: Context Map → Integration Pattern → Domain Event 설계

컨텍스트 간 관계를 구체적 통합 메커니즘으로 변환하는 단계

핵심 활동:

• Context Map 해석: 컨텍스트 간 관계 분석
• Integration Pattern 선택: 적절한 통합 방식 결정
• Domain Event 설계: 비동기 통신 이벤트 정의

입력물 (Input):

출력물 (Output):

핵심 의사결정:

• 동기 vs 비동기: 실시간 응답이 필요한가?
• 강결합 vs 약결합: 컨텍스트 독립성이 중요한가?
• 일관성 수준: 즉시 일관성 vs 최종 일관성

4 단계: Subdomain 분류 → Module 구조 → Package/Namespace 조직화

도메인 분류를 물리적 코드 구조로 변환하는 최종 단계

핵심 활동:

• Subdomain 분류 적용: Core/Supporting/Generic 우선순위 반영
• Module 구조 설계: 패키지/네임스페이스 조직화
• 코드 구조 정의: 디렉터리 및 파일 구조 결정

입력물 (Input):

출력물 (Output):

조직화 원칙:

1. 도메인 우선: 기술 레이어보다 도메인 개념으로 그룹화
2. 응집성: 함께 변경되는 코드를 함께 배치
3. 낮은 결합도: 모듈 간 의존성 최소화

단계별 변환 과정 예시: 전자상거래 도메인 분석

변환 단계:

1. 도메인 탐색 → Bounded Context 식별 → Aggregate 후보 발견
2. Ubiquitous Language → Entity/Value Object 명명 → 메서드 시그니처 정의
3. Context Map → Integration Pattern → Domain Event 설계
4. Subdomain 분류 → Module 구조 → Package/Namespace 조직화

1 단계: 도메인 탐색 → Bounded Context 식별 → Aggregate 후보 발견

핵심 활동:

• 도메인 탐색 (Domain Exploration): 비즈니스 프로세스와 규칙 이해
• Bounded Context 식별: 일관된 모델 경계 정의
• Aggregate 후보 발견: 트랜잭션 일관성 단위 식별

도메인 탐색 결과:
- 핵심 비즈니스 프로세스: 상품 진열 → 장바구니 → 주문 → 결제 → 배송
- 도메인 전문가 식별: 상품 관리자, 주문 관리자, 배송 담당자, 고객 서비스

Bounded Context 식별:

1
2
3
4
5
6
7

E-commerce Domain
├── Product Catalog Context (상품 카탈로그)
├── Shopping Cart Context (장바구니)  
├── Order Management Context (주문 관리)
├── Payment Context (결제)
├── Shipping Context (배송)
└── Customer Context (고객 관리)

Aggregate 후보 발견:

2 단계: Ubiquitous Language → Entity/Value Object 명명 → 메서드 시그니처 정의

핵심 활동:

• Ubiquitous Language 적용: 비즈니스 용어를 클래스/메서드명으로 변환
• Entity/Value Object 구분: 식별자 유무에 따른 객체 분류
• 메서드 시그니처 정의: 비즈니스 행동을 메서드로 구체화

언어 구체화 실무 예시:

• 비즈니스 용어 → 도메인 객체 변환:

1
2
3
4
5
6
7
8
9

비즈니스 용어          → Entity/Value Object     → 메서드 시그니처
─────────────────────────────────────────────────────────────
"상품을 장바구니에 담기"  → Cart.addProduct()      → void addProduct(ProductId, Quantity)
"주문 취소"           → Order.cancel()         → OrderResult cancel(CancellationReason)
"배송 시작"           → Shipment.start()       → void start(DeliveryAddress, EstimatedDate)
"결제 승인"           → Payment.approve()      → PaymentResult approve(Amount, PaymentMethod)
"재고 확인"           → Product.checkStock()   → StockLevel checkStock(Quantity)
"할인 적용"           → Cart.applyDiscount()   → Money applyDiscount(DiscountCode)
"주문 상태 변경"       → Order.updateStatus()  → void updateStatus(OrderStatus, Timestamp)

• Value Object 설계 예시:

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

# 비즈니스 용어: "금액과 통화"
class Money:
	def __init__(self, amount: Decimal, currency: str):
		if amount < 0:
			raise ValueError("금액은 음수일 수 없습니다")
		self._amount = amount
		self._currency = currency
	
	def add(self, other: 'Money') -> 'Money':
		if self._currency != other._currency:
			raise ValueError("다른 통화는 더할 수 없습니다")
		return Money(self._amount + other._amount, self._currency)

# 비즈니스 용어: "배송 주소"
class DeliveryAddress:
	def __init__(self, street: str, city: str, postal_code: str, country: str):
		self._street = street
		self._city = city
		self._postal_code = postal_code
		self._country = country
	
	def get_delivery_zone(self) -> DeliveryZone:
		# 배송 구역 결정 로직
		pass

3 단계: Context Map → Integration Pattern → Domain Event 설계

핵심 활동:

• Context Map 해석: 컨텍스트 간 관계 분석
• Integration Pattern 선택: 적절한 통합 방식 결정
• Domain Event 설계: 비동기 통신 이벤트 정의

컨텍스트 통합 패턴 예시

• Context 관계 매핑:

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

Order Context (Upstream) → Payment Context (Downstream)
관계: Customer/Supplier
패턴: Open Host Service
구현: PaymentAPI

Shopping Cart Context ↔ Product Catalog Context  
관계: Partnership
패턴: Shared Kernel
구현: ProductSharedModel

Order Context → Shipping Context
관계: Publisher/Subscriber  
패턴: Domain Events
구현: OrderPlacedEvent, ShipmentRequestedEvent

• Domain Event 설계 예시:

 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

# Order Context에서 발생하는 이벤트
@dataclass
class OrderPlacedEvent:
	order_id: OrderId
	customer_id: CustomerId
	total_amount: Money
	shipping_address: DeliveryAddress
	occurred_at: datetime
	items: List[OrderItem]

# Payment Context에서 소비하는 이벤트  
@dataclass
class PaymentRequiredEvent:
	order_id: OrderId
	amount: Money
	payment_method: PaymentMethod
	due_date: datetime

# Shipping Context에서 발생하는 이벤트
@dataclass  
class ShipmentStartedEvent:
	shipment_id: ShipmentId
	order_id: OrderId
	tracking_number: TrackingNumber
	estimated_delivery: datetime

4 단계: Subdomain 분류 → Module 구조 → Package/Namespace 조직화

핵심 활동:

• Subdomain 분류 적용: Core/Supporting/Generic 우선순위 반영
• Module 구조 설계: 패키지/네임스페이스 조직화
• 코드 구조 정의: 디렉터리 및 파일 구조 결정

모듈 구조 실무 예시:

• Subdomain 분류와 Module 매핑:

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

Core Domain → Primary Modules
├── com.ecommerce.catalog.domain
├── com.ecommerce.order.domain  
└── com.ecommerce.cart.domain

Supporting Domain → Secondary Modules
├── com.ecommerce.customer.domain
├── com.ecommerce.inventory.domain
└── com.ecommerce.notification.domain

Generic Domain → Infrastructure Modules  
├── com.ecommerce.payment.infrastructure
├── com.ecommerce.shipping.infrastructure
└── com.ecommerce.authentication.infrastructure

• 패키지 구조 상세:

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

com.ecommerce.order.domain/
├── model/
│   ├── Order.java              # Aggregate Root
│   ├── OrderItem.java          # Entity  
│   ├── OrderStatus.java        # Value Object
│   ├── ShippingAddress.java    # Value Object
│   └── Money.java              # Shared Value Object
├── service/
│   ├── OrderService.java       # Domain Service
│   └── PricingService.java     # Domain Service
├── repository/
│   └── OrderRepository.java    # Repository Interface
├── event/
│   ├── OrderPlacedEvent.java   # Domain Event
│   └── OrderCancelledEvent.java
└── factory/
	└── OrderFactory.java       # Factory

고급 변환 패턴

Event Storming 에서 Tactical Design 으로의 변환

Event Storming 결과 → Aggregate 설계:

graph LR
    subgraph "Event Storming 결과"
        E1[ProductViewed]
        E2[ProductAddedToCart]  
        E3[CartCheckedOut]
        E4[PaymentProcessed]
        E5[OrderShipped]
    end
    
    subgraph "Tactical Design 변환"
        A1[Product Aggregate]
        A2[Cart Aggregate]
        A3[Order Aggregate] 
        A4[Payment Aggregate]
        A5[Shipment Aggregate]
    end
    
    E1 --> A1
    E2 --> A2
    E3 --> A3
    E4 --> A4
    E5 --> A5

실제 코드 변환 예시

Strategic Design 결정사항:

• Product Catalog Context 에서 " 상품 " 은 진열과 검색에 중점
• Order Context 에서 " 상품 " 은 주문 항목과 가격에 중점

Tactical Design 구현:

 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

# Product Catalog Context의 Product
class CatalogProduct:
    def __init__(self, product_id: ProductId, name: str, description: str):
        self._id = product_id
        self._name = name
        self._description = description
        self._categories: List[Category] = []
        self._images: List[ProductImage] = []
    
    def add_to_category(self, category: Category):
        """상품을 카테고리에 추가"""
        self._categories.append(category)
    
    def update_description(self, new_description: str):
        """상품 설명 업데이트"""
        self._description = new_description

# Order Context의 Product (다른 관점)
class OrderProduct:
    def __init__(self, product_id: ProductId, price: Money, weight: Weight):
        self._id = product_id
        self._price = price
        self._weight = weight
    
    def calculate_shipping_cost(self, destination: DeliveryAddress) -> Money:
        """배송비 계산 (주문 컨텍스트의 관심사)"""
        return self._weight.calculate_shipping_cost(destination)

변환 시 주의사항 및 모범 사례

체계적인 변환 과정을 통해 Strategic Design 의 비즈니스 인사이트가 Tactical Design 의 구체적인 코드 구조로 정확하게 번역되며, 유지보수 가능하고 진화 가능한 시스템을 구축할 수 있다.

언어 일관성 유지

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 좋은 예: 비즈니스 용어 직접 사용
class Order:
    def place_order(self): pass
    def cancel_order(self): pass
    def ship_order(self): pass

# 나쁜 예: 기술적 용어 사용  
class Order:
    def create(self): pass
    def delete(self): pass  
    def update_status(self): pass

Context 경계 명확화

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

# Order Context
class OrderCustomer:
    def __init__(self, customer_id: CustomerId, shipping_address: Address):
        self._id = customer_id
        self._shipping_address = shipping_address

# Customer Context  
class Customer:
    def __init__(self, customer_id: CustomerId, profile: CustomerProfile):
        self._id = customer_id
        self._profile = profile
        self._loyalty_points = LoyaltyPoints()

이벤트 기반 통합

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

# Context 간 통신을 위한 이벤트
class OrderPlacedEvent:
    def __init__(self, order_id: OrderId, items: List[OrderItem]):
        self.order_id = order_id
        self.items = items
        self.occurred_at = datetime.now()

# 다른 Context에서 이벤트 처리
class InventoryService:
    def handle_order_placed(self, event: OrderPlacedEvent):
        for item in event.items:
            self.reserve_stock(item.product_id, item.quantity)

상향식 피드백 (Tactical → Strategic)

도메인 모델과 소프트웨어는 도메인 전문가와 사용자의 피드백을 바탕으로 지속적으로 개선된다. 이를 통해 비즈니스 도메인이 진화함에 따라 소프트웨어가 정확하고 관련성을 유지할 수 있다.

피드백 유형:

실무 피드백 패턴:

피드백의 트리거 조건:

• 복잡성 임계값 (Complexity Thresholds)
  • 예시
    • Aggregate 가 7 개 이상의 Entity 를 포함할 경우, 경계가 너무 넓을 수 있으므로 해당 Bounded Context 의 분할을 검토.
    • 사이클 복잡도 (Cyclomatic Complexity) 가 15 를 초과하는 경우, 도메인 서비스로 로직을 분리하거나 리팩토링이 필요.
    • Context 간 호출이 분당 100 회를 넘는다면, 과도한 결합을 의미할 수 있으므로 통합 방식 (예: ACL, 이벤트 기반 통신 등) 을 재검토.
    • 도메인 용어의 불일치 비율이 30% 이상이라면, 공유 언어 (Ubiquitous Language) 정립을 위한 워크샵을 통해 용어 정비가 필요.

• 성능 임계값 (Performance Thresholds)

  • 예시:

    1 2 3

    Query Response Time > 500ms → CQRS 패턴 도입 Transaction Rollback > 5% → Aggregate 경계 재설계 Context Coupling > 80% → Context Map 재구성

지속적 개선 사이클

graph LR
    A[Strategic Design] --> B[Tactical Implementation]
    B --> C[실행 경험]
    C --> D[학습 및 발견]
    D --> A
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#e8f5e8
    style D fill:#fff3e0

순방향 흐름 (Top-Down):

• 비즈니스 도메인 → 전략적 설계 → Bounded Context 정의 → 전술적 설계 적용 → 구현 계층 반영

피드백 흐름 (Bottom-Up):

• 전술적 설계에서의 학습과 발견 → 전략적 설계 개선 → 도메인 이해 심화

이러한 순환적 관계를 통해 DDD 는 단순한 설계 방법론을 넘어 지속적으로 진화하는 도메인 이해의 프레임워크가 된다.

협력적 학습 메커니즘 (Collaborative Learning)

DDD 에서 전략적 설계와 전술적 설계의 균형을 맞추기 위해서는 이해관계자와의 협력이 필수적이다. 개발자는 이해관계자와 긴밀히 협력하여 소프트웨어 시스템이 비즈니스 요구사항을 만족하고 비즈니스 목표와 일치하도록 해야 한다.

협력 패턴

graph LR
    DE[Domain Expert] --> WS[Workshop Sessions]
    WS --> ES[Event Storming]
    ES --> BC[Bounded Context]
    BC --> AG[Aggregate Design]
    AG --> FB[Feedback to Domain]
    FB --> DE
    
    subgraph "Learning Cycle"
        ES --> UL[Ubiquitous Language]
        UL --> CODE[Code Implementation]
        CODE --> REVIEW[Domain Review]
        REVIEW --> UL
    end

이 상호작용적 발견 과정은 이해관계자, 도메인 전문가, 개발자가 함께 작업하여 도메인 이벤트의 흐름, 원인, 효과를 시각화하고 도메인에 대한 공유된 이해를 촉진한다.

진화적 수렴 메커니즘 (Evolutionary Convergence)

Strategic 과 Tactical Design 은 수렴 진화 (Convergent Evolution) 패턴을 보인다. 서로 다른 출발점에서 시작하여 점차 일치된 도메인 모델로 수렴해간다.

수렴 지표:

• Language Consistency: 코드 명명과 비즈니스 용어의 일치도
• Model Stability: Aggregate 경계의 안정성
• Integration Efficiency: Context 간 통신의 효율성
• Business Alignment: 비즈니스 규칙과 코드 로직의 일치성

구현 기법

Strategic Design 구현 기법

Tactical Design 구현 기법

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

실무 사용 예시

산업 도메인별 DDD 적용 사례

시스템 아키텍처/설계 적용 사례

조직 및 협업/커뮤니케이션 중심 활용

구현 및 테스트 관점 실무 활용

활용 사례

사례 1: 글로벌 이커머스 플랫폼의 주문 - 결제 - 배송 도메인

시스템 구성:

• 주문, 결제, 배송 각각 별도의 바운디드 컨텍스트
• 각 컨텍스트 내에 엔티티, 값 객체, 애그리게이트, 도메인 서비스, 이벤트, 리포지토리 존재

구조 다이어그램

graph TD
    subgraph 주문 컨텍스트
        OrderEntity
        OrderAggregate
        OrderService
        OrderEvent
        OrderRepository
    end
    subgraph 결제 컨텍스트
        PaymentEntity
        PaymentAggregate
        PaymentService
        PaymentEvent
        PaymentRepository
    end
    subgraph 배송 컨텍스트
        DeliveryEntity
        DeliveryAggregate
        DeliveryService
        DeliveryEvent
        DeliveryRepository
    end
    OrderEvent -.-> PaymentService
    PaymentEvent -.-> DeliveryService

Workflow:

1. 주문 생성 → 주문 이벤트 발생
2. 결제 컨텍스트에서 주문 이벤트 수신 후 결제 처리
3. 결제 성공 시 결제 이벤트 발생
4. 배송 컨텍스트에서 결제 이벤트 수신 후 배송 처리

역할:

• 도메인 전문가: 요구사항 정의, 유비쿼터스 언어 정립
• 개발자: 도메인 모델 설계/구현
• QA: 도메인 이벤트 기반 테스트

사례 2: 카카오페이 여신코어 시스템 구축

시스템 구성

• 카카오페이는 복잡한 여신 업무를 위해 DDD 를 적용하여 시스템을 구축.

시스템 구성도:

graph TB
    subgraph "프레젠테이션 계층"
        A[여신 관리 API]
        B[대출 신청 API]
        C[심사 결과 API]
    end
    
    subgraph "응용 계층"
        D[여신 신청 서비스]
        E[심사 처리 서비스]
        F[납부 관리 서비스]
    end
    
    subgraph "도메인 계층"
        G[대출 애그리거트]
        H[고객 애그리거트]
        I[심사 애그리거트]
        J[납부 애그리거트]
    end
    
    subgraph "인프라 계층"
        K[여신 DB]
        L[외부 신용평가 API]
        M[알림 시스템]
    end
    
    A --> D
    B --> D
    C --> E
    D --> G
    E --> I
    F --> J
    G --> K
    I --> L
    J --> M

Workflow:

sequenceDiagram
    participant C as 고객
    participant API as 여신 API
    participant APP as 응용 서비스
    participant LOAN as 대출 애그리거트
    participant REVIEW as 심사 애그리거트
    participant EXT as 외부 신용평가
    
    C->>API: 대출 신청
    API->>APP: 대출 신청 처리
    APP->>LOAN: 대출 생성
    LOAN->>LOAN: 신청 정보 검증
    LOAN-->>APP: 대출 신청 완료 이벤트
    APP->>REVIEW: 심사 시작
    REVIEW->>EXT: 신용 정보 조회
    EXT-->>REVIEW: 신용 정보 응답
    REVIEW->>REVIEW: 심사 규칙 적용
    REVIEW-->>APP: 심사 완료 이벤트
    APP->>LOAN: 심사 결과 반영
    API-->>C: 대출 승인 결과

DDD 역할 및 효과:

1. 유비쿼터스 언어 정립: 금융 도메인의 복잡한 용어를 개발자와 금융 전문가가 공통으로 사용
2. 바운디드 컨텍스트 분리: 대출, 심사, 납부 등 각 영역의 독립적 발전 가능
3. 애그리거트 설계: 복잡한 여신 규칙을 대출 애그리거트 내에서 일관성 있게 관리
4. 도메인 이벤트 활용: 비동기 처리를 통한 시스템 성능 향상

기존 시스템과의 차이점:

• 기존: 절차 지향적 처리, 데이터베이스 중심 설계
• DDD 적용 후: 도메인 중심 설계, 비즈니스 로직의 명확한 표현, 변화에 유연한 대응

사례 3: 온라인 음식 배달 플랫폼

시스템 구성:

graph TB
    subgraph "Customer Management Context"
        A[Customer]
        B[Customer Profile]
        C[Loyalty Program]
    end
    
    subgraph "Restaurant Management Context"
        D[Restaurant]
        E[Menu]
        F[Restaurant Profile]
    end
    
    subgraph "Order Management Context"
        G[Order]
        H[Order Item]
        I[Payment]
    end
    
    subgraph "Delivery Context"
        J[Delivery]
        K[Driver]
        L[Route]
    end
    
    A --> G
    D --> G
    G --> J
    K --> J

Workflow:

sequenceDiagram
    participant C as Customer
    participant O as Order Service
    participant R as Restaurant
    participant P as Payment Service
    participant D as Delivery Service
    
    C->>O: 주문 생성
    O->>R: 주문 확인 요청
    R->>O: 주문 승인
    O->>P: 결제 처리
    P->>O: 결제 완료
    O->>D: 배달 요청
    D->>C: 배달원 배정 알림
    D->>C: 배달 완료

DDD 역할 담당:

1. Strategic Design:

   • Bounded Context 식별 (고객관리, 주문관리, 배달관리)
   • Context Map 을 통한 통합 지점 정의

2. Tactical Design:

   • Order Aggregate: 주문 일관성 보장
   • Domain Events: OrderPlaced, PaymentCompleted, DeliveryStarted
   • Repository: 각 Aggregate 에 대한 영속성 관리

3. Ubiquitous Language: " 주문 “, " 배달 “, " 음식점 " 등 비즈니스 용어 코드에 반영

사례 4: 헬스케어 조직–환자 관리 시스템

목적: 환자 관리 (Patient Management) 를 별도의 Bounded Context 로 분리하여 개발 독립성 확보

시스템 구성:

graph LR
  PatientB(ctx:환자관리) --> BillingB(ctx:청구)
  PatientB --> AppointmentB(ctx:예약)

구성요소:

• Strategic: Bounded Context 분리, Context Map 작성, Ubiquitous Language 정의
• Tactical: 환자 Entity, 주소 ValueObject, Repository, DomainService 구현

Workflow:

1. 워크숍 통해 환자 - 주소 - 진료 이벤트 도출 (EventStorming)
2. 환자 컨텍스트에서 Entity/VO 구현
3. 청구/예약 컨텍스트와 OCR/ACL 방식으로 통합
4. 독립 서비스로 배포 및 이벤트 기반 연동 설계

사례 5: 전자상거래 시스템 사례

시스템 구성:

• 대형 온라인 쇼핑몰의 도메인 주도 설계 적용 사례로, 다음과 같은 컨텍스트들로 구성되었다:
  • 주문 관리 컨텍스트 (Order Management)
  • 상품 카탈로그 컨텍스트 (Product Catalog)
  • 재고 관리 컨텍스트 (Inventory Management)
  • 결제 처리 컨텍스트 (Payment Processing)
  • 배송 관리 컨텍스트 (Shipping Management)

시스템 구성 다이어그램

graph TB

%% Strategic Design - Context Map
subgraph "Strategic Design - Context Map"
    OC[Order Context]
    PC[Product Catalog Context]
    IC[Inventory Context]
    PayC[Payment Context]
    SC[Shipping Context]

    OC -->|Customer/Supplier| PC
    OC -->|Customer/Supplier| IC
    OC -->|Customer/Supplier| PayC
    OC -->|Customer/Supplier| SC
    PC -->|Shared Kernel| IC
end

%% Tactical Design - Order Context
subgraph "Tactical Design - Order Context"
    OR[Order Aggregate Root]
    OI[Order Item Entity]
    Addr[Address Value Object]
    Money[Money Value Object]

    OR --> OI:::composition
    OR --> Addr:::composition
    OI --> Money:::composition
end

%% Style for composition
classDef composition stroke-width:2px,stroke-dasharray: 5 5

Workflow 다이어그램

sequenceDiagram
    participant Customer
    participant OrderService
    participant ProductCatalog
    participant Inventory
    participant Payment
    participant Shipping
    
    Customer->>OrderService: 주문 생성 요청
    OrderService->>ProductCatalog: 상품 정보 조회
    ProductCatalog-->>OrderService: 상품 정보 반환
    OrderService->>Inventory: 재고 확인
    Inventory-->>OrderService: 재고 상태 반환
    OrderService->>Payment: 결제 처리 요청
    Payment-->>OrderService: 결제 완료 확인
    OrderService->>Shipping: 배송 요청
    OrderService-->>Customer: 주문 완료 응답

각 설계 접근법의 역할:

• Strategic Design 의 역할:
  • 비즈니스 도메인을 5 개의 명확한 경계 컨텍스트로 분리
  • 각 컨텍스트 간의 관계를 Customer/Supplier, Shared Kernel 패턴으로 정의
  • 팀 조직을 컨텍스트 경계에 맞춰 구성 (Conway’s Law 적용)
• Tactical Design 의 역할:
  • Order Aggregate 를 통한 주문 일관성 보장
  • Value Object (Money, Address) 를 통한 불변성 확보
  • Repository 패턴을 통한 데이터 접근 추상화

차이점 비교

구현 예시

온라인 쇼핑몰 주문 처리 시스템 (Python)

  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
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397

# Domain-Driven Design 기반 온라인 쇼핑몰 주문 시스템

from abc import ABC, abstractmethod
from dataclasses import dataclass
from datetime import datetime
from decimal import Decimal
from enum import Enum
from typing import List, Optional
from uuid import UUID, uuid4

# ============================================================================
# 1. 도메인 계층 (Domain Layer)
# ============================================================================

# 밸류 오브젝트 (Value Objects)
@dataclass(frozen=True)  # 불변성 보장
class Money:
    """금액을 표현하는 밸류 오브젝트"""
    amount: Decimal
    currency: str = "KRW"
    
    def add(self, other: 'Money') -> 'Money':
        if self.currency != other.currency:
            raise ValueError("다른 통화는 더할 수 없습니다")
        return Money(self.amount + other.amount, self.currency)
    
    def multiply(self, multiplier: int) -> 'Money':
        return Money(self.amount * multiplier, self.currency)

@dataclass(frozen=True)
class CustomerId:
    """고객 ID를 표현하는 밸류 오브젝트"""
    value: UUID
    
    @classmethod
    def generate(cls) -> 'CustomerId':
        return cls(uuid4())

@dataclass(frozen=True)
class Address:
    """배송 주소를 표현하는 밸류 오브젝트"""
    street: str
    city: str
    postal_code: str
    country: str = "KR"
    
    def __post_init__(self):
        if not self.street or not self.city or not self.postal_code:
            raise ValueError("주소 정보가 불완전합니다")

# 도메인 이벤트 (Domain Events)
@dataclass
class DomainEvent:
    """도메인 이벤트 기본 클래스"""
    event_id: UUID
    occurred_at: datetime
    aggregate_id: UUID

@dataclass
class OrderCreated(DomainEvent):
    """주문 생성 이벤트"""
    customer_id: UUID
    total_amount: Money

@dataclass
class OrderItemAdded(DomainEvent):
    """주문 항목 추가 이벤트"""
    product_id: UUID
    quantity: int
    price: Money

# 열거형 (Enums)
class OrderStatus(Enum):
    DRAFT = "DRAFT"
    CONFIRMED = "CONFIRMED"
    PAID = "PAID"
    SHIPPED = "SHIPPED"
    DELIVERED = "DELIVERED"
    CANCELLED = "CANCELLED"

# 엔티티 (Entities)
class OrderItem:
    """주문 항목 엔티티"""
    def __init__(self, product_id: UUID, quantity: int, unit_price: Money):
        if quantity <= 0:
            raise ValueError("수량은 0보다 커야 합니다")
        if unit_price.amount <= 0:
            raise ValueError("가격은 0보다 커야 합니다")
            
        self.product_id = product_id
        self.quantity = quantity
        self.unit_price = unit_price
    
    def calculate_total(self) -> Money:
        """항목별 총액 계산"""
        return self.unit_price.multiply(self.quantity)
    
    def change_quantity(self, new_quantity: int):
        """수량 변경"""
        if new_quantity <= 0:
            raise ValueError("수량은 0보다 커야 합니다")
        self.quantity = new_quantity

class Order:
    """주문 애그리거트 루트"""
    def __init__(self, customer_id: CustomerId, shipping_address: Address):
        self.id = uuid4()
        self.customer_id = customer_id
        self.shipping_address = shipping_address
        self.status = OrderStatus.DRAFT
        self.created_at = datetime.now()
        self.items: List[OrderItem] = []
        self._domain_events: List[DomainEvent] = []
    
    def add_item(self, product_id: UUID, quantity: int, unit_price: Money):
        """주문 항목 추가"""
        if self.status != OrderStatus.DRAFT:
            raise ValueError("확정된 주문은 수정할 수 없습니다")
        
        # 기존 항목 확인
        existing_item = self._find_item(product_id)
        if existing_item:
            existing_item.change_quantity(existing_item.quantity + quantity)
        else:
            item = OrderItem(product_id, quantity, unit_price)
            self.items.append(item)
        
        # 도메인 이벤트 추가
        self._add_domain_event(OrderItemAdded(
            event_id=uuid4(),
            occurred_at=datetime.now(),
            aggregate_id=self.id,
            product_id=product_id,
            quantity=quantity,
            price=unit_price
        ))
    
    def remove_item(self, product_id: UUID):
        """주문 항목 제거"""
        if self.status != OrderStatus.DRAFT:
            raise ValueError("확정된 주문은 수정할 수 없습니다")
        
        self.items = [item for item in self.items if item.product_id != product_id]
    
    def calculate_total(self) -> Money:
        """주문 총액 계산"""
        if not self.items:
            return Money(Decimal('0'))
        
        total = self.items[0].calculate_total()
        for item in self.items[1:]:
            total = total.add(item.calculate_total())
        return total
    
    def confirm_order(self):
        """주문 확정"""
        if self.status != OrderStatus.DRAFT:
            raise ValueError("이미 확정된 주문입니다")
        if not self.items:
            raise ValueError("주문 항목이 없습니다")
        
        self.status = OrderStatus.CONFIRMED
        
        # 주문 생성 이벤트 발행
        self._add_domain_event(OrderCreated(
            event_id=uuid4(),
            occurred_at=datetime.now(),
            aggregate_id=self.id,
            customer_id=self.customer_id.value,
            total_amount=self.calculate_total()
        ))
    
    def ship_order(self):
        """주문 배송"""
        if self.status != OrderStatus.PAID:
            raise ValueError("결제된 주문만 배송 가능합니다")
        self.status = OrderStatus.SHIPPED
    
    def _find_item(self, product_id: UUID) -> Optional[OrderItem]:
        """상품 ID로 주문 항목 찾기"""
        return next((item for item in self.items if item.product_id == product_id), None)
    
    def _add_domain_event(self, event: DomainEvent):
        """도메인 이벤트 추가"""
        self._domain_events.append(event)
    
    def get_domain_events(self) -> List[DomainEvent]:
        """도메인 이벤트 조회"""
        return self._domain_events.copy()
    
    def clear_domain_events(self):
        """도메인 이벤트 초기화"""
        self._domain_events.clear()

# 도메인 서비스 (Domain Services)
class OrderDomainService:
    """주문 도메인 서비스"""
    
    @staticmethod
    def can_apply_discount(order: Order, discount_percentage: Decimal) -> bool:
        """할인 적용 가능 여부 판단"""
        return (order.status == OrderStatus.DRAFT and 
                order.calculate_total().amount >= Decimal('100000') and
                discount_percentage <= Decimal('0.3'))
    
    @staticmethod
    def calculate_shipping_fee(order: Order) -> Money:
        """배송료 계산"""
        total = order.calculate_total()
        if total.amount >= Decimal('50000'):
            return Money(Decimal('0'))  # 무료배송
        return Money(Decimal('3000'))   # 기본 배송료

# 리포지토리 인터페이스 (Repository Interface)
class OrderRepository(ABC):
    """주문 리포지토리 인터페이스"""
    
    @abstractmethod
    def save(self, order: Order) -> None:
        """주문 저장"""
        pass
    
    @abstractmethod
    def find_by_id(self, order_id: UUID) -> Optional[Order]:
        """ID로 주문 조회"""
        pass
    
    @abstractmethod
    def find_by_customer_id(self, customer_id: CustomerId) -> List[Order]:
        """고객 ID로 주문 목록 조회"""
        pass

# ============================================================================
# 2. 응용 계층 (Application Layer)
# ============================================================================

@dataclass
class CreateOrderCommand:
    """주문 생성 커맨드"""
    customer_id: UUID
    shipping_address: Address
    items: List[dict]  # [{"product_id": UUID, "quantity": int, "unit_price": Decimal}]

@dataclass
class AddOrderItemCommand:
    """주문 항목 추가 커맨드"""
    order_id: UUID
    product_id: UUID
    quantity: int
    unit_price: Decimal

class OrderApplicationService:
    """주문 응용 서비스"""
    
    def __init__(self, order_repository: OrderRepository):
        self.order_repository = order_repository
    
    def create_order(self, command: CreateOrderCommand) -> UUID:
        """주문 생성"""
        customer_id = CustomerId(command.customer_id)
        order = Order(customer_id, command.shipping_address)
        
        # 주문 항목 추가
        for item_data in command.items:
            order.add_item(
                product_id=item_data["product_id"],
                quantity=item_data["quantity"],
                unit_price=Money(Decimal(str(item_data["unit_price"])))
            )
        
        self.order_repository.save(order)
        return order.id
    
    def add_order_item(self, command: AddOrderItemCommand):
        """주문 항목 추가"""
        order = self.order_repository.find_by_id(command.order_id)
        if not order:
            raise ValueError("주문을 찾을 수 없습니다")
        
        order.add_item(
            command.product_id,
            command.quantity,
            Money(Decimal(str(command.unit_price)))
        )
        
        self.order_repository.save(order)
    
    def confirm_order(self, order_id: UUID):
        """주문 확정"""
        order = self.order_repository.find_by_id(order_id)
        if not order:
            raise ValueError("주문을 찾을 수 없습니다")
        
        order.confirm_order()
        self.order_repository.save(order)
        
        # 이벤트 처리 (실제로는 이벤트 버스로 발행)
        events = order.get_domain_events()
        for event in events:
            print(f"이벤트 발행: {event}")
        order.clear_domain_events()

# ============================================================================
# 3. 인프라스트럭처 계층 (Infrastructure Layer)
# ============================================================================

class InMemoryOrderRepository(OrderRepository):
    """인메모리 주문 리포지토리 구현체"""
    
    def __init__(self):
        self._orders: dict[UUID, Order] = {}
    
    def save(self, order: Order) -> None:
        """주문 저장"""
        self._orders[order.id] = order
    
    def find_by_id(self, order_id: UUID) -> Optional[Order]:
        """ID로 주문 조회"""
        return self._orders.get(order_id)
    
    def find_by_customer_id(self, customer_id: CustomerId) -> List[Order]:
        """고객 ID로 주문 목록 조회"""
        return [order for order in self._orders.values() 
                if order.customer_id == customer_id]

# ============================================================================
# 4. 프레젠테이션 계층 (Presentation Layer)
# ============================================================================

class OrderController:
    """주문 컨트롤러"""
    
    def __init__(self, order_service: OrderApplicationService):
        self.order_service = order_service
    
    def create_order(self, request_data: dict) -> dict:
        """주문 생성 API"""
        try:
            command = CreateOrderCommand(
                customer_id=UUID(request_data["customer_id"]),
                shipping_address=Address(**request_data["shipping_address"]),
                items=request_data["items"]
            )
            
            order_id = self.order_service.create_order(command)
            return {"success": True, "order_id": str(order_id)}
            
        except Exception as e:
            return {"success": False, "error": str(e)}

# ============================================================================
# 5. 사용 예시
# ============================================================================

if __name__ == "__main__":
    # 의존성 주입 설정
    repository = InMemoryOrderRepository()
    service = OrderApplicationService(repository)
    controller = OrderController(service)
    
    # 주문 생성 예시
    request = {
        "customer_id": str(uuid4()),
        "shipping_address": {
            "street": "강남대로 123",
            "city": "서울",
            "postal_code": "06234"
        },
        "items": [
            {
                "product_id": uuid4(),
                "quantity": 2,
                "unit_price": "25000"
            },
            {
                "product_id": uuid4(),
                "quantity": 1,
                "unit_price": "15000"
            }
        ]
    }
    
    result = controller.create_order(request)
    print("주문 생성 결과:", result)
    
    if result["success"]:
        order_id = UUID(result["order_id"])
        
        # 주문 확정
        service.confirm_order(order_id)
        print("주문이 확정되었습니다.")
        
        # 주문 조회
        order = repository.find_by_id(order_id)
        if order:
            print(f"주문 상태: {order.status}")
            print(f"주문 총액: {order.calculate_total().amount} {order.calculate_total().currency}")

도메인 계층

classDiagram
    direction TB
    
    %% Aggregate Root
    class Order {
        <<Aggregate Root>>
        - id: UUID
        - customerId: CustomerId
        - shippingAddress: Address
        - status: OrderStatus
        - createdAt: datetime
        - items: List~OrderItem~
        - _domainEvents: List~DomainEvent~
        + addItem(productId: UUID, quantity: int, unitPrice: Money)
        + removeItem(productId: UUID)
        + calculateTotal(): Money
        + confirmOrder()
        + shipOrder()
        + getDomainEvents(): List~DomainEvent~
        + clearDomainEvents()
        - _findItem(productId: UUID): OrderItem
        - _addDomainEvent(event: DomainEvent)
    }
    
    %% Entities
    class OrderItem {
        <<Entity>>
        - productId: UUID
        - quantity: int
        - unitPrice: Money
        + calculateTotal(): Money
        + changeQuantity(newQuantity: int)
    }
    
    %% Value Objects
    class Money {
        <<Value Object>>
        - amount: Decimal
        - currency: string
        + add(other: Money): Money
        + multiply(multiplier: int): Money
    }
    
    class CustomerId {
        <<Value Object>>
        - value: UUID
        + generate(): CustomerId
    }
    
    class Address {
        <<Value Object>>
        - street: string
        - city: string
        - postalCode: string
        - country: string
    }
    
    %% Enumerations
    class OrderStatus {
        <<enumeration>>
        DRAFT
        CONFIRMED
        PAID
        SHIPPED
        DELIVERED
        CANCELLED
    }
    
    %% Domain Events
    class DomainEvent {
        <<Abstract>>
        - eventId: UUID
        - occurredAt: datetime
        - aggregateId: UUID
    }
    
    class OrderCreated {
        <<Domain Event>>
        - customerId: UUID
        - totalAmount: Money
    }
    
    class OrderItemAdded {
        <<Domain Event>>
        - productId: UUID
        - quantity: int
        - price: Money
    }
    
    %% Domain Service
    class OrderDomainService {
        <<Domain Service>>
        + canApplyDiscount(order: Order, discountPercentage: Decimal): bool
        + calculateShippingFee(order: Order): Money
    }
    
    %% Repository Interface
    class OrderRepository {
        <<interface>>
        + save(order: Order): void
        + findById(orderId: UUID): Order
        + findByCustomerId(customerId: CustomerId): List~Order~
    }
    
    %% 관계 설정
    Order --> "1..*" OrderItem : aggregates
    Order --> "1" CustomerId : contains
    Order --> "1" Address : contains
    Order --> "1" OrderStatus : has
    Order --> "*" DomainEvent : publishes
    OrderItem --> "1" Money : uses
    
    DomainEvent <|-- OrderCreated : extends
    DomainEvent <|-- OrderItemAdded : extends
    
    OrderDomainService ..> Order : operates on
    OrderRepository ..> Order : manages

응용/프레젠테이션/인프라 계층

classDiagram
    direction TB
    
    %% Presentation Layer
    class OrderController {
        <<Controller>>
        - orderService: OrderApplicationService
        + createOrder(requestData: dict): dict
    }
    
    %% Application Layer
    class OrderApplicationService {
        <<Application Service>>
        - orderRepository: OrderRepository
        + createOrder(command: CreateOrderCommand): UUID
        + addOrderItem(command: AddOrderItemCommand): void
        + confirmOrder(orderId: UUID): void
    }
    
    %% Commands (Application Layer)
    class CreateOrderCommand {
        <<Command>>
        - customerId: UUID
        - shippingAddress: Address
        - items: List~dict~
    }
    
    class AddOrderItemCommand {
        <<Command>>
        - orderId: UUID
        - productId: UUID
        - quantity: int
        - unitPrice: Decimal
    }
    
    %% Infrastructure Layer
    class InMemoryOrderRepository {
        <<Repository Implementation>>
        - _orders: dict~UUID, Order~
        + save(order: Order): void
        + findById(orderId: UUID): Order
        + findByCustomerId(customerId: CustomerId): List~Order~
    }
    
    %% Repository Interface (from Domain)
    class OrderRepository {
        <<interface>>
        + save(order: Order): void
        + findById(orderId: UUID): Order
        + findByCustomerId(customerId: CustomerId): List~Order~
    }
    
    %% Domain Reference (for context)
    class Order {
        <<Aggregate Root>>
        - id: UUID
        - customerId: CustomerId
        - status: OrderStatus
        + confirmOrder()
        + addItem()
        + calculateTotal(): Money
    }
    
    class Address {
        <<Value Object>>
        - street: string
        - city: string
        - postalCode: string
        - country: string
    }
    
    %% 관계 설정
    OrderController --> OrderApplicationService : uses
    OrderApplicationService --> OrderRepository : depends on
    OrderApplicationService --> CreateOrderCommand : processes
    OrderApplicationService --> AddOrderItemCommand : processes
    
    OrderRepository <|.. InMemoryOrderRepository : implements
    
    CreateOrderCommand --> Address : contains
    OrderApplicationService ..> Order : creates and manages
    InMemoryOrderRepository --> Order : stores

데이터 플로우

1. 요청 처리: OrderController → OrderApplicationService
2. 커맨드 변환: HTTP Request → Command Object
3. 도메인 로직 실행: Application Service → Domain Objects
4. 데이터 영속화: Application Service → Repository
5. 응답 생성: Domain Objects → DTO → HTTP Response

추가 개선 및 확장 가능 부분

결제 (Payment) 도메인 추가

classDiagram
    class Payment {
        - paymentId: UUID
        - orderId: UUID
        - amount: Money
        - paymentMethod: PaymentMethod
        - status: PaymentStatus
        - processedAt: datetime
        + process()
        + refund(amount: Money)
        + cancel()
    }
    
    class PaymentMethod {
        <<enumeration>>
        CREDIT_CARD
        BANK_TRANSFER
        KAKAO_PAY
        NAVER_PAY
    }
    
    class PaymentStatus {
        <<enumeration>>
        PENDING
        COMPLETED
        FAILED
        REFUNDED
        CANCELLED
    }
    
    Payment --> PaymentMethod
    Payment --> PaymentStatus
    Payment --> Money

재고 (Inventory) 도메인 추가

classDiagram
    class Product {
        - productId: UUID
        - name: string
        - price: Money
        - inventory: Inventory
        + updatePrice(newPrice: Money)
        + isAvailable(quantity: int): bool
    }
    
    class Inventory {
        - productId: UUID
        - currentStock: int
        - reservedStock: int
        - minimumStock: int
        + reserve(quantity: int)
        + release(quantity: int)
        + restock(quantity: int)
        + getAvailableStock(): int
    }
    
    Product --> Inventory
    Product --> Money

이벤트 소싱 (Event Sourcing) 패턴 적용

CQRS (Command Query Responsibility Segregation) 적용

classDiagram
    %% 커맨드 사이드
    class OrderCommandHandler {
        + handle(CreateOrderCommand)
        + handle(AddOrderItemCommand)
        + handle(ConfirmOrderCommand)
    }
    
    %% 쿼리 사이드
    class OrderQueryHandler {
        + handle(GetOrderByIdQuery): OrderDto
        + handle(GetOrdersByCustomerQuery): List~OrderDto~
        + handle(GetOrderSummaryQuery): OrderSummaryDto
    }
    
    class OrderDto {
        - orderId: string
        - customerName: string
        - totalAmount: decimal
        - status: string
        - createdAt: datetime
    }
    
    class OrderSummaryDto {
        - totalOrders: int
        - totalRevenue: decimal
        - averageOrderValue: decimal
    }
    
    OrderQueryHandler --> OrderDto
    OrderQueryHandler --> OrderSummaryDto

도메인 검증 강화

성능 최적화 패턴

classDiagram
    class OrderProjection {
        - orderId: UUID
        - customerName: string
        - totalAmount: decimal
        - itemCount: int
        - lastUpdated: datetime
        + updateFromEvent(event: DomainEvent)
    }
    
    class OrderCache {
        - cache: Map~UUID, OrderProjection~
        + get(orderId: UUID): OrderProjection
        + put(orderId: UUID, projection: OrderProjection)
        + invalidate(orderId: UUID)
    }
    
    class OrderStatistics {
        - totalOrders: long
        - totalRevenue: Money
        - averageOrderValue: Money
        + updateFromOrderCreated(event: OrderCreated)
        + updateFromOrderCancelled(event: OrderCancelled)
    }
    
    OrderCache --> OrderProjection

보안 및 권한 관리

모니터링 및 관찰 가능성

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

# 메트릭스 (Metrics) 예시
@dataclass
class OrderMetrics:
    """주문 관련 메트릭스"""
    orders_created_total: int
    orders_confirmed_total: int
    orders_cancelled_total: int
    average_order_value: Decimal
    order_processing_duration: float

# 분산 추적 (Distributed Tracing) 예시
@dataclass
class TraceContext:
    """분산 추적 컨텍스트"""
    trace_id: str
    span_id: str
    parent_span_id: Optional[str]
    operation_name: str

이러한 확장을 통해 더욱 견고하고 확장 가능한 도메인 주도 설계 기반 시스템을 구축할 수 있다. 각 패턴과 구성 요소는 시스템의 복잡성과 요구사항에 따라 단계적으로 도입하는 것을 권장한다.

장점

단점 및 문제점

단점

문제점

Anemic Domain Model 문제

원인: 비즈니스 로직이 Service Layer 에 집중되어 Domain Object 가 데이터만 담는 현상
영향: 도메인 모델의 캡슐화 파괴, 비즈니스 로직 분산
탐지 및 진단: Entity 와 Value Object 에 getter/setter 만 존재하는지 검사
예방 방법: Entity 와 Value Object 에 비즈니스 로직 포함, Tell Don’t Ask 원칙 적용
해결 방법:

 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

# 문제 있는 코드 (Anemic)
class Order:
    def __init__(self):
        self.total = 0
        self.items = []
    
    def get_total(self):
        return self.total
    
    def set_total(self, total):
        self.total = total

# 개선된 코드 (Rich Domain Model)
class Order:
    def __init__(self):
        self._total = 0
        self._items = []
    
    def add_item(self, item):
        self._items.append(item)
        self._calculate_total()
    
    def _calculate_total(self):
        self._total = sum(item.get_subtotal() for item in self._items)
    
    @property
    def total(self):
        return self._total

Repository 패턴 오용

원인: Repository 를 단순 DAO 로 사용하거나 비즈니스 로직 포함
영향: 관심사 분리 원칙 위배, 테스트 어려움
탐지 및 진단: Repository 에 비즈니스 로직이나 복잡한 쿼리 로직 존재 여부 확인
예방 방법: Repository 인터페이스를 도메인 관점에서 정의
해결 방법:

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

# 잘못된 예시
class CustomerRepository:
    def find_customers_with_high_value_orders(self, threshold):
        # 복잡한 비즈니스 로직이 Repository에 포함됨
        pass

# 올바른 예시
class CustomerRepository:
    def find_by_specification(self, specification):
        # 도메인 사양 객체를 통한 검색
        pass

class HighValueCustomerSpecification:
    def __init__(self, threshold):
        self.threshold = threshold
    
    def is_satisfied_by(self, customer):
        return customer.get_total_order_value() > self.threshold

도전 과제 및 해결책

조직 및 협업 과제

설계 및 모델링 과제

기술 및 아키텍처 과제

레거시 통합 과제

운영 및 테스트 과제

비즈니스/외부 환경 과제

기술 트렌드 관련 과제

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