Using tactical DDD to design microservices

도메인 주도 설계(DDD)는 전체 시스템에 대해 단일 통합 모델을 갖는다는 개념에 반대합니다. 대신 시스템을 각각 고유한 모델을 갖는 경계가 있는 컨텍스트(bounded contexts)로 분할하는 것을 권장합니다. DDD의 전략적 단계에서는 비즈니스 도메인을 매핑하고 도메인 모델에 대한 경계가 있는 컨텍스트를 정의합니다.

전술적 DDD는 도메인 모델을 보다 정밀하게 정의하는 것입니다. 전술적 패턴은 단일 경계가 있는 컨텍스트 내에서 적용됩니다. 각 경계가 있는 컨텍스트가 마이크로서비스 후보인 마이크로서비스 아키텍처에서 우리는 특히 엔터티 및 집계 패턴에 관심이 있습니다. 이러한 패턴을 적용하면 애플리케이션의 서비스에 대한 자연스러운 경계를 식별하는 데 도움이 됩니다(이 시리즈의 다음 문서 참조). 일반 원칙으로 마이크로서비스는 집계보다 작지 않고 경계가 있는 컨텍스트보다 크지 않아야 합니다. 먼저 전술적 패턴을 검토합니다. 그런 다음 Drone Delivery 애플리케이션의 Shipping 경계가 있는 컨텍스트에 적용합니다.

Overview of the tactical patterns

이 섹션에서는 전술적 DDD 패턴에 대한 간략한 요약을 제공하므로 이미 DDD에 익숙하다면 이 섹션을 건너뛸 수 있습니다. 패턴은 Eric Evans의 책 5~6장과 Vaughn Vernon의 Implementing Domain-Driven Design에서 더 자세히 설명합니다.

Entities

엔터티는 시간이 지나도 지속되는 고유한 식별자(Identity)를 가진 객체 입니다.
예를 들어, 은행 애플리케이션에서 고객(Customer)과 계좌(Account)는 엔터티 입니다.

• 엔터티는 시스템 내에서 고유한 식별자(Identifier) 를 가집니다.
  • 이를 이용해 엔터티를 조회하거나 검색할 수 있습니다.
  • 하지만 이 식별자가 반드시 사용자에게 직접 노출되는 것은 아닙니다.
  • 예를 들어, GUID 또는 데이터베이스의 기본 키(Primary Key) 를 사용할 수 있습니다.
• 식별자는 여러 경계 컨텍스트(Bounded Contexts)에 걸쳐 존재할 수 있으며, 애플리케이션의 수명보다 더 오래 지속될 수 있습니다.
  • 예: 은행 계좌 번호, 정부 발급 신분증(ID) 등은 특정 애플리케이션의 수명과 무관하게 존재합니다.
• 엔터티의 속성(Attribute)은 시간이 지나면서 변경될 수 있습니다.
  • 예: 사람의 이름(Name)이나 주소(Address)가 변경될 수 있지만, 동일한 사람임
• 엔터티는 다른 엔터티를 참조(Reference)할 수도 있습니다.

Value Objects

값 객체는 고유한 식별자(Identity)가 없으며, 속성 값 자체로 정의되는 객체 입니다.

• 값 객체는 불변(Immutable)해야 합니다.
• 값 객체를 업데이트하려면, 기존 객체를 변경하는 것이 아니라 새로운 인스턴스를 생성하여 교체해야 합니다.
• 값 객체는 도메인 로직을 캡슐화하는 메서드를 가질 수 있지만,
  • 객체 상태에 영향을 주는 부작용(Side Effect)은 없어야 합니다.

✅ 일반적인 값 객체(Value Object) 예시:

• 색상(Color)
• 날짜 및 시간(Dates and Times)
• 화폐 단위 및 금액(Currency Values)

Aggregates

애그리게이트는 하나 이상의 엔터티를 감싸는 일관성(consistency) 경계를 정의 합니다.

• 하나의 애그리게이트에는 반드시 하나의 루트 엔터티(Root Entity) 가 존재합니다.
• 조회(Lookup)는 루트 엔터티의 식별자(Identifier) 를 사용하여 수행됩니다.
• 애그리게이트 내부의 다른 엔터티는 루트 엔터티를 통해서만 접근할 수 있습니다.

✅ 애그리게이트의 목적:

• 트랜잭션 불변성(Transactional Invariants) 을 모델링
• 현실 세계에서 복잡한 관계를 가진 객체들(Customer, Orders, Products, Suppliers 등) 을 처리

✅ 데이터 일관성(Consistency) 유지 방식:

• 전통적인 애플리케이션 → 데이터베이스 트랜잭션을 사용하여 일관성을 보장
• 분산 애플리케이션(Distributed Application) →
  • 단일 트랜잭션을 여러 데이터 저장소에 걸쳐 적용하는 것이 어렵습니다.
  • 트랜잭션이 장시간 실행(Long-running transaction) 되거나 서드파티 서비스가 포함될 수 있습니다.
  • 따라서, 데이터 계층(Data Layer)이 아니라 애플리케이션(Application)이 직접 일관성을 보장해야 합니다.
  • 애그리게이트는 이러한 도메인 불변성을 모델링 하는 역할을 합니다.

Domain Services 및 Application Services

DDD에서 서비스(Service)는 상태를 가지지 않고 특정 로직을 수행하는 객체 입니다.
Eric Evans는 서비스를 두 가지 유형 으로 구분합니다.

1️⃣ 도메인 서비스(Domain Services)

• 도메인 로직(Domain Logic)을 캡슐화 하는 역할
• 여러 엔터티(Entity) 간의 동작을 조정하는 비즈니스 로직 을 구현

2️⃣ 애플리케이션 서비스(Application Services)

• 기술적인 기능(Technical Functionality)을 제공
• 예: 사용자 인증(Authentication), SMS 메시지 전송(Sending an SMS) 등

✅ 도메인 서비스는 엔터티를 조작하는 복잡한 비즈니스 로직을 처리하는 데 사용됩니다.

Domain Events

도메인 이벤트는 시스템 내에서 중요한 일이 발생했음을 알리는 이벤트 입니다.

📌 도메인 이벤트의 특징:

• 도메인 이벤트는 도메인 내에서 의미가 있어야 합니다.
  • ❌ 잘못된 예: "레코드가 테이블에 삽입됨" (도메인과 직접적인 관련 없음)
  • ✅ 올바른 예: "배송이 취소됨(A Delivery Was Cancelled)" (도메인에서 중요한 사건)

📌 마이크로서비스에서 도메인 이벤트의 역할:

• 마이크로서비스는 분산되어 있고, 데이터를 공유하지 않습니다.
• 도메인 이벤트는 마이크로서비스 간의 조정을 가능하게 하는 중요한 도구입니다.

📌 비동기 메시징(Asynchronous Messaging)과의 관계:

• "Interservice communication" 글에서는 비동기 메시징을 통한 마이크로서비스 간 통신 에 대해 더 자세히 다룹니다.

기타 DDD 패턴

위에서 설명한 패턴 외에도 DDD에는 몇 가지 추가적인 패턴이 있습니다.

• 팩토리(Factory)
• 리포지토리(Repository)
• 모듈(Modules)

이러한 패턴들은 마이크로서비스를 구현할 때 유용하지만, 마이크로서비스의 경계를 설계하는 과정에서는 상대적으로 덜 중요 합니다.

Drone delivery: Applying the patterns

먼저, 배송(Shipping) 경계 컨텍스트 가 처리해야 할 주요 시나리오를 정의합니다.

📌 배송(Shipping) 경계 컨텍스트의 주요 시나리오

1. 고객은 드론 배송 서비스에 등록된 비즈니스에서 상품을 픽업 하도록 요청할 수 있습니다.
2. 발송인은 패키지에 태그(바코드 또는 RFID)를 생성하여 부착 합니다.
3. 드론이 패키지를 픽업하여 목적지까지 배송 합니다.
4. 고객이 배송을 예약하면,
   • 시스템은 경로 정보, 날씨 조건, 과거 데이터 를 기반으로 ETA(예상 도착 시간) 을 제공합니다.
5. 드론이 비행 중일 때,
   • 사용자는 현재 위치 및 최신 ETA를 실시간으로 추적 할 수 있습니다.
6. 드론이 패키지를 픽업하기 전까지,
   • 고객은 배송을 취소할 수 있습니다.
7. 배송이 완료되면, 고객에게 알림(Notification)이 전송됩니다.
8. 발송인은 고객의 배송 확인(Signature 또는 지문 확인)을 요청 할 수 있습니다.
9. 사용자는 완료된 배송 내역을 조회 할 수 있습니다.

📌 엔터티(Entity) 및 애그리게이트(Aggregate) 식별

위의 시나리오를 분석한 후, 개발팀은 다음과 같은 엔터티(Entity) 를 정의했습니다.

• Delivery (배송)
• Package (패키지)
• Drone (드론)
• Account (사용자 계정)
• Confirmation (배송 확인)
• Notification (알림)
• Tag (패키지 태그)

✅ 애그리게이트(Aggregates) 식별
아래 네 개의 엔터티는 각각 하나의 애그리게이트를 형성하며, 트랜잭션 일관성(Consistency) 경계를 가집니다.

• Delivery (배송)
• Package (패키지)
• Drone (드론)
• Account (사용자 계정)

✅ 하위 엔터티(Child Entities) 식별

• Confirmations (배송 확인) 및 Notifications (알림) 은 배송(Delivery)의 하위 엔터티 입니다.
• Tags (패키지 태그) 는 패키지(Package)의 하위 엔터티 입니다.

✅ 값 객체(Value Objects) 식별
아래 값 객체들은 식별자(Identity)를 가지지 않으며, 속성 값 자체로 정의됩니다.

• Location (위치)
• ETA (예상 도착 시간)
• PackageWeight (패키지 무게)
• PackageSize (패키지 크기)

📌 UML 다이어그램을 통한 설명

• UML 다이어그램에서 Delivery 애그리게이트 는
  • Account, Package, Drone과 같은 다른 애그리게이트와의 참조(Reference)를 포함 하고 있습니다.
• 이를 통해 마이크로서비스 간의 관계를 모델링 하고,
  • 트랜잭션 일관성을 유지하는 방식 을 정의할 수 있습니다.

📌 두 가지 도메인 이벤트(Domain Events)

1️⃣ 드론 상태 이벤트(DroneStatus Events)

• 드론이 비행 중일 때(While a drone is in flight),
  • 드론(Drone) 엔터티 는 드론 상태 이벤트(DroneStatus Events) 를 전송합니다.
  • 이 이벤트는 드론의 위치 및 상태(비행 중, 착륙함 등) 를 설명합니다.

2️⃣ 배송 추적 이벤트(DeliveryTracking Events)

• 배송(Delivery) 엔터티 는
  • 배송 단계(Stage)가 변경될 때마다 배송 추적 이벤트(DeliveryTracking Events) 를 전송합니다.
• 포함되는 이벤트 유형:
  • DeliveryCreated (배송 생성됨)
  • DeliveryRescheduled (배송 일정 변경됨)
  • DeliveryHeadedToDropoff (배송이 목적지로 이동 중)
  • DeliveryCompleted (배송 완료됨)

✅ 이벤트의 특징

• 이 이벤트들은 도메인 모델 내에서 의미가 있는 일들을 설명합니다.
• 즉, 특정 프로그래밍 언어의 특정 구현 방식과는 독립적 입니다.
• 오직 도메인 내에서 중요한 변화만을 반영하는 것 이 핵심입니다.

📌 새로운 기능 추가: 스케줄링 및 모니터링

개발팀은 기존 엔터티(Entity)들로는 적절히 포함하기 어려운 기능적인 역할 을 추가로 발견했습니다.
즉, 배송을 예약하거나 업데이트하는 과정에서 여러 단계가 조정될 필요가 있습니다.

이에 따라, 두 개의 도메인 서비스(Domain Services) 를 설계에 추가했습니다.

1️⃣ Scheduler (스케줄러)

• 배송 스케줄링 및 업데이트와 관련된 모든 단계를 조정(Coordinate)하는 역할

2️⃣ Supervisor (감독자)

• 각 단계의 상태(Status)를 모니터링
• 단계가 실패하거나(Failed), 시간 초과(Timed Out)되었는지 감지하는 역할

✅ 이 설계는 "Scheduler Agent Supervisor" 패턴의 변형(Variation)입니다.

• 즉, 스케줄러가 작업을 조정하고, 감독자는 작업의 상태를 감시하는 방식 입니다.

 

 

 

다음 단계

다음 단계는 각 마이크로서비스의 경계를 정의하는 것 입니다.

 

출처 : https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd