DDD 지향 마이크로 서비스 디자인

DDD를 배우기 시작한 꽑꽑이가 정리한 우당탕탕 정리입니다. 글 아래에 참고 사이트, 문서를 정리해두었으니 참고해주세요.

DDD(Domain Driven Development)는 사용 사례와 관련하여 현실의 비즈니스에 근거한 모델링을 대표한다.

 

애플리케이션 빌드의 컨텍스트에서 DDD는 문제를 도메인으로 설명한다.

경계가 정해진 컨텍스트로 독립적인 문제 영역을 설명하며 문제 해결에 관해 설명하는 공통 언어를 강조한다.

내부 구현을 지원을 위해 많은 모델, Value Object, Aggregate, Aggregate Root(or Root Entity) 규칙이 있는 도메인 엔티티처럼 여러 기술적 개념과 패턴도 제시한다.

중요한 것은 패턴 자체가 아니라 비즈니스 문제에 맞게 코드를 구성하고 동일한 비즈니스 용어(유비쿼터스 언어)를 사용하는 것이다.

또한 DDD 방법은 중대한 비즈니스 규칙이 있는 복잡한 마이크로 서비스를 구현할 때만 적용해야 한다. CRUD 서비스처럼 더 간단한 업무는 더 간단한 방법으로 관리할 수 있다.

MSA 설계 및 정의를 할 때는 그 경계를 정하는 것이 핵심이다. 

DDD 패턴은 도메인의 복잡성을 이해하는 데 도움이 된다. 

경계가 지정된 각 컨텍스트(BoundedContext)에 대한 도메인 모델의 경우 도메인을 모델링하기 위한 엔터티, Value Object, Aggregate 를 식별하여 정의한다.

마이크로 서비스 컨텍스트 경계를 상대적으로 작게 유지

 컨텍스트 사이에서 어디를 경계로 할 것인지는 결정하는 것은 경합하는 두 목표의 균형을 맞추는 것이다. 

첫 번째, 가능한 가장 작은 마이크로 서비스를 만들려고 한다. 응집이 필요한 항목 주변의 경계를 만들어야 한다.

두 번째, 마이크로 서비스 간의 자잘한 통신은 지양한다. 

세 번째, 경계가 지정된 새 컨텍스트를 분리할 때마다 매번 통신 경계가 신속하게 늘어나도록 시스템을 가능한 작은 규모의 여러 마이크로 서비스로 나누어 그 균형을 맞추어야 한다. 응집력은 경계가 지정된 단일 컨텍스트에서 핵심이다.

출처 : https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7

 

클래스를 구현할 때 두 마이크로 서비스가 서로 협력하는 일이 많을 경우 동일한 마이크로 서비스가 되어야 할 수 있다. (부적절한 친밀감)
마이크로 서비스가 다른 서비스에 의존하여 요청을 직접 서비스해야 할 경우 진정한 자율성이라 할 수 없다.

DDD 마이크로 서비스의 계층

비즈니스 및 기술 복잡성이 높은 대부분의 엔터프라이즈 애플리케이션은 여러 계층으로 정의된다.

계층은 논리적 아티팩트로, 서비스 배포와 관련이 없고, 개발자가 코드에서 복잡성을 관리하는 데 도움이 되기 위한 것이다.

또한 Aggregate Root에서 제어되는 항상 유효한 엔티티가 필요하다. 

복잡성을 해결할 때는 도메인 모델을 엔티티 그룹(Aggregate)과 관련한 모든 고정 및 규칙이 단일 진입지점 또는 게이트인 Aggregate Root를 통해 수행되도록 하는 Aggregate에서 제어하는 것이 중요하다.

 

도메인 모델 계층

비즈니스 개념, 비즈니스 상황 정보, 비즈니스 규칙을 나타낸다. 

저장을 위한 기술 세부 정보는 인프라에 위임되지만 비즈니스 상황을 반영한 상태가 여기서 제어 및 사용된다. 

이 계층은 비즈니스  소프트웨어의 핵심이다

지속성 무시 ◁및 인프라 무시 원칙◁에 따라 이 계층은 완전히 데이터 지속성 세부 정보를 무시해야 한다.

도메인 모델 엔티티가 POCO 여야 하는 것이 중요한 규칙이다.

도메인 엔티티는 데이터 액세스 인프라 프레임워크에 직접적인 종속성을 갖지 않아야 한다.

하지만, 도메인 모델에 대해 지속성 무시 원칙을 따르는 것이 중요하더라도 무시해서는 안된다.

물리적 데이터 모델과 이 모델이 엔티티 개채 모델에 매핑되는 방식을 이해하는 것은 여전히 중요하다.
그렇지 않으면 불가능한 설계를 만들 수 있다.

스토리지 기술과 ORM 기술에 모두 근거하여 엔티티 모델이 준수해야 하는 제약이 여전히 존재한다.

 

애플리케이션 계층

소프트웨어가 수행할 작업을 정의하고 표현적 도메인 객체가 문제를 해결하도록 지시한다.

이 계층은 담당하는 작업은 비즈니스에 유의미하거나, 다른 시스템의 애플리케이션 계층과 상호 작용에 필요하다.

이 계층은 가볍게 유지된다. 비즈니스 규칙을 포함하지 않으며 작업을 조정, 업무 위임만 한다.

비즈니스 상태를 갖지 않지만 사용자 또는 프로그램에 대해 작업의 진행 상황을 반영하는 상태는 가질 수 있다.

도메인 모델 계층의 도메인 논리, 데이터 모델, 관련 비즈니스 규칙이 프레젠테이션 및 애플리케이션 계층에서 완전히 독립적이 되게 하는 것이 목표이다.

무엇보다 도메인 모델 계층은 인프라 프레임워크에 직접적으로 종속되어서는 안 된다.

 

인프라 계층

 최초에 도메인 엔티티에 있던 데이터가 데이터베이스나 기타 영구 저장소에 유지되는 방식이다.

앞에서 언급한 지속성 무시 및 인프라 무시 원칙에 따라 인프라 계층은 도메인 모델 계층을 "오염" 시키지 않아야 한다.

도메인 모델 계층 클래스 라이브러리에는 자체 도메인 코드인 소프트웨어의 핵심을 구현하는 POCO 엔티티 소프트웨어만 있어야 하며 인프라 기술과는 완전히 분리되어야 한다.

DDD 서비스의 종속성, 애플리케이션 계층은 도메인 및 인프라에 따라 다르며 인프라는 도메인에 종속되지만 도메인은 모든 계층에 종속되지 않는다. 

이 계층 설계는 각각의 마이크로 서비스마다 독립적이다.

정리

Aggregate는 도메인 모델을 엔티티 그룹, Aggregate에는 관련한 모든 고정 및 규칙이 단일 진입지점 또는 게이트인 Aggregate Root를 통해 수행되도록 하는 Aggregate에서 제어하는 것이 중요하다.
ex)
- 주문 애그리게잇 : Order, Order Item, Order History
- 주문 애그리것 루트 : Order
- 사용자 애그리게잇 : User, User Information
- 사용자 애그리것 루트 : User

도메인 엔티티는 데이터 액세스 인프라 프레임워크에 직접적인 종속성을 갖지 않아야 한다.

모든 데이터 액세스 작업은 Aggregate Root를 통해서 한다.

다음 공부

이벤트 스토밍과 DDD : https://ducktyping.tistory.com/20

이벤트 스토밍과 DDD

참고 사이트

- 마이크로서비스 도큐먼트 : DDD 중심 마이크로 서비스 설계
https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

DDD 중심 마이크로 서비스 설계

- 리팩터링 냄시나는 코드
https://sourcemaking.com/refactoring/smells/inappropriate-intimacy

Design Patterns and Refactoring

 

- 마이크로서비스 도큐먼트 : 도메인 모델 레이어에서 유효성 검사 디자인
https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-model-layer-validations

도메인 모델 레이어에서 유효성 검사 디자인

- https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7

Modelling Reactive Systems with Event Storming and Domain-Driven Design

- https://ducktyping.tistory.com/15?category=1180172 

DDD Aggregate