도메인 엔터티 패턴 - 마이크로 서비스 도메인 모델 디자인
도메인 엔터티 패턴
엔터티는 도메인 개체를 대표하며, 주로 ID, 연속성, 시간의 흐름에 따른 지속성 및 이들을 포괄하는 특성에 의해 정의된다.
기본적으로 해당 ID로 정의되는 개체를 엔터티라고 한다.
‘엔터티 ID는 다중 마이크로 서비스나 바인딩된 컨텍스트를 교차할 수 있습니다.’
동일한 ID(즉, 동일한 도메인 엔터티는 아닐 수 있지만 동일한 Id 값)는 여러 바인딩된 컨텍스트 또는 마이크로 서비스 전체에 걸쳐 모델링될 수 있다. 그러나 동일한 특성 및 논리를 가진 동일한 엔터티가 다중 바인딩된 컨텍스트에서 구현된다는 의미는 아니다. 대신, 각 바운딩된 컨텍스트의 엔터티는 그 속성과 행동을 해당 바운딩된 컨텍스트의 도메인에서 요구하는 속성과 동작에 맞게 제한한다.
구매자 엔터티는 ID를 포함해 프로필이나 ID 마이크로 서비스의 사용자 엔터티에서 정의되는 사람의 특성 대부분을 가질 수 있다. 그러나 주문형 마이크로 서비스에서 구매자 엔터티는 특성을 거의 가질 수 없는데 특정 구매자 데이터만 주문 프로세스에 관련돼 있기 때문이다. 각 마이크로 서비스의 컨텍스트 또는 바인딩된 컨텍스트는 해당 도메인 모델에 영향을 준다.
도메인 엔터티는 데이터 특성을 구현하는 것 외에도 동작을 구현해야 합니다.
DDD에서 도메인 엔터티는 엔터티 데이터(메모리에 액세스된 개체)와 관련된 도메인 논리나 행동을 구현해야 한다. 예를 들어, 주문 엔터티 클래스의 일부로서 주문 항목, 데이터 유효성 검사, 총계를 추가하는 것 같은 작업 메서드로서 구현된 비즈니스 작업 및 논리가 포함돼야 한다. 해당 엔터티의 메서드는 애플리케이션 계층에 엔터티 규칙을 분산하는 대신 엔터티의 규칙 및 고정화에 신경을 써야 한다.
도메인 모델 엔터티는 메서드를 통해 동작을 구현한다. 즉, 이는 "빈약한" 모델이 아니다. 물론, 경우에 따라 엔터티 클래스의 일부로 모든 논리를 구현하지는 않는 엔터티를 포함할 수 있다. 이런 경우는 대부분의 논리가 집계 루트에서 정의되기 때문에 자식 엔터티가 특별한 논리를 갖지 않은 경우 집계하지 않는 자식 엔터티에서 발생할 수 있다. 도메인 엔터티 대신 서비스 클래스에서 구현된 논리를 갖는 복잡한 마이크로 서비스가 포함된 경우 다음 섹션에서 설명될 빈약한 도메인 모델이 될 수 있다.
가치 개체 패턴 (Value object pattern)
“많은 개체는 개념적 ID를 갖고 있지 않습니다. 이런 개체는 사물의 일정한 특성을 설명합니다.”
마이크로 서비스의 엔터티인 어떤 것이 또 다른 마이크로 서비스의 엔터티가 될 수는 없다. 두 번째 경우에 바운딩된 컨텍스트가 다른 의미를 가질 수 있기 때문이다.
예를 들어, 전자 상거래 애플리케이션의 주소는 개인 또는 회사에 대해 고객 프로필의 특성 그룹을 나타낼 수 있기에 ID를 전혀 가질 수 없다. 이 경우, 해당 주소는 가치 개체로 분류돼야 한다.
그러나 전원 유틸리티 회사의 애플리케이션에서 고객 주소는 비즈니스 도메인에 대해 중요할 수 있다. 따라서 해당 주소는 청구 시스템이 직접 해당 주소에 연결될 수 있도록 반드시 ID를 가져야 한다. 이 경우, 주소는 도메인 엔터티로 분류돼야 한다.
사람은 ID를 가지므로 성과 이름이 있는 사람은 대개 엔터티이다. 이는 하나의 성과 이름이 서로 다른 두 사람을 지칭하는 경우와 같이 다른 값 집합과 성과 이름이 일치할 때도 마찬가지다.
가치 개체는 EF(Entity Framework) 같은 ORM과 관계형 데이터베이스에서는 관리하기가 어렵다. 반면에 문서 지향 데이터베이스에서는 구현과 사용이 훨씬 쉽다.
집계 모듈
도메인 모델은 주문 완료나 재고 등의 중요한 기능 영역을 제어할 수 있는 다른 데이터 엔터티 및 프로세스의 클러스터를 포함한다. 더욱 정교한 DDD 단위는 응집력 있는 단위로 취급될 수 있는 동작 및 엔터티의 그룹이나 클러스터를 설명하는 집계다.
일반적으로 필요한 트랜잭션을 기반으로 집계를 정의한다. 전형적인 예는 주문 항목 목록을 포함하는 주문이다. 주문 항목은 대개 엔터티가 되지만, 일반적으로 집계 루트라고 하는 해당 루트 엔터티로서 주문 엔터티를 포함하는 주문 집계 내에서 자식 엔터티가 된다.
집계를 식별하기는 어려울 수 있다. 집계는 서로 일치 해야 하는 개체 그룹이지만 개체 그룹을 막 선택하고 이를 집계라고 레이블을 붙일 수 없다. 도메인 개념부터 시작해서 해당 개념과 관련된 가장 일반적인 트랜잭션에서 사용되는 엔터티를 고려해야 한다. 트랜잭션 관점에서 일관성이 있는 이런 엔터티가 집계를 형성하는 것이다. 트랜잭션 작업에 대한 생각이 아마도 집계를 식별하는 가장 좋은 방법이다.
집계 루트 또는 루트 엔터티 패턴
집계는 최소 하나 이상의 엔터티로 구성돼있다. 루트 엔터티 또는 기본 엔터티라고도 하는 집계 루트다. 또한 집계는 모든 엔터티 및 개체가 필요한 동작 및 트랜잭션을 구현하기 위해 함께 작업하는 가운데 여러 자식 엔터티와 가치 개체를 가질 수 있다.
집계 루트의 목적은 집계의 일관성을 확보하는 데 있으며, 집계 루트 클래스에서 메서드나 작업을 통해 집계를 업데이트하기 위한 유일한 진입점이 되어야 한다. 집계 루트를 통해서만 집계 내에서 엔터티를 변경해야 한다. 집계의 일관성 보호자는 집계를 위해 준수해야 할 모든 고정불변 및 일관성 규칙을 고려해야 한다. 독립적으로 자식 엔터티나 가치 개체를 변경하는 경우 집계 루트는 집계가 유효한 상태인지를 보장할 수 없다. 이는 마치 느슨한 다리를 가진 테이블과 같다. 일관성을 유지하는 것은 집계 루트의 주요 목적이다.
아래 그림에서, 단일 엔터티(집계 루트 구매자)를 포함하는 구매자 집계 같은 샘플 집계를 확인할 수 있다. 해당 구매 집계는 여러 엔터티 및 가치 개체를 포함한다.
DDD 도메인 모델은 집계로 구성되며, 집계는 하나 이상의 엔터티만 가질 수 있으며 값 개체도 포함할 수 있다. 구매자 집계는 eShopOnContainers 참조 애플리케이션의 주문 마이크로 서비스에서 그러는 것처럼 해당 도메인에 따라 추가적인 자식 엔터티를 가질 수 있음에 유의해야 한다. 위 그림은 구매자가 집계 루트만 포함된 집계의 예로서 단일 엔터티를 갖고 있음을 보여준다.
집계 분리를 유지하고 집계 간에 명확한 경계를 유지하기 위해서는 eShopOnContainers에서 마이크로 서비스 도메인 모델 주문하기에서 구현된 것처럼 외래 키(FK) 필드만 갖고 집계 간 직접 탐색을 허용하지 않는 것이 DDD 도메인 모델의 좋은 관행이다. 주문 엔터티는 다음 코드에 나와 있는 것처럼 EF Core 탐색 속성이 아닌 구매자를 위한 외래 키 필드만 갖는다.
요약
엔터티
-도메인 개체를 대표
- 바운딩된 컨텍스트의 엔터티는 그 속성과 행동을 해당 바운딩된 컨텍스트의 도메인에서 요구하는 속성과 동작에 맞게 제한
도메인 엔터티
-엔터티 데이터(메모리에 액세스된 개체)와 관련된 도메인 논리나 행동을 구현해야 한다
-작업 메서드로서 구현된 비즈니스 작업 및 논리가 포함돼야 한다
도메인 모델 엔터티
- 메서드를 통해 동작을 구현한다.
- 대부분의 논리가 집계 루트에서 정의되기 때문에 자식 엔터티가 특별한 논리를 갖지 않은 경우 집계하지 않는 자식 엔터티에서 발생할 수 있다
도메인 모델
-중요한 기능 영역을 제어할 수 있는 다른 데이터 엔터티 및 프로세스의 클러스터를 포함한다.
-일반적으로 필요한 트랜잭션을 기반으로 집계를 정의한다.
집계
-최소 하나 이상의 엔터티로 구성
-여러 자식 엔터티와 가치 개체를 가질 수 있다.
-집계 루트를 통해서만 집계 내에서 엔터티를 변경해야 한다.
DDD 도메인 모델
-집계로 구성되며, 집계는 하나 이상의 엔터티만 가질 수 있으며 값 개체도 포함할 수 있다
'Architecture' 카테고리의 다른 글
| REPR 디자인 패턴 개념 / REPR - MVC 비교 / REPR-REST 비교 (0) | 2023.11.27 |
|---|---|
| CQRS 패턴이란? CQRS Pattern (0) | 2023.11.09 |
