DDD : - 개념을 그 역사와 함께 모델링하는 방법?

Question

SignupRequest이라는 집계가 있으며이 집계 기록을 추적해야합니다. 요청은 받아 들여지거나 금지됩니다. 이러한 비즈니스 개념을 모델링하는 데 선호하는 솔루션은 무엇입니까 ?? 1- signupRequest의 기록을 관리하는 데 사용되는 signupRequestHistory 집계를 만듭니다. 2- SignupRequest에는 SignupRequestHistory 값 개체의 컬렉션이 포함됩니다.

• SignupRequestHistory는 요청 자체에 대한 추적 기록 (변경 불가능한 데이터) 입니다. 이러한 기록 데이터에 대한 비즈니스 상수는 없습니다.
• 예를 들어 Subscriber 및 SubscriberHistory와 같은 개념이 적용되었으므로 깨끗한 패턴이 필요합니다.
• 또한 기록은보고 용 일뿐입니다 당신이 언급 한 바와 같이 목적

Answer 1

, 당신은 SignupRequest의 상태와 변화의 날짜/시간을 보유하고 SignupRequestHistory 집계를 만들 수 있습니다.

SignupRequest에는 SignupRequestHistory 값 개체의 컬렉션이 포함됩니다.

SignupRequest에 컬렉션을 추가하기 전에 왜 그 일을하고 있는지 생각해야합니다. SignupRequest에 SignupRequestHistory 콜렉션이 필요하지 않은 첫 번째 표시 인 "no business invariants exists"가 지정되었습니다.

정확한 도메인을 모르지만 SignupRequestHistory은 실제로 그 도메인의 일부가 아닙니다. 비즈니스 문제를 해결하는 데 사용되지 않으며 엄격하게보고/시각적 요구 사항입니다. SignupRequestHistory이 실제로 나타내는 것은 도메인 이벤트, 즉 도메인의 상태 변경입니다. 이것은 당신이 Event Sourcing으로부터 이익을 얻을 것이라고 믿게합니다.

모든 도메인 이벤트를 소스로 사용하면 집계 루트 발생은 이벤트 저장소에 순서대로 저장됩니다. 집계의 상태가 변경 될 때마다 향후 사용을 위해 저장되는 이벤트가 발생합니다. 이렇게하면 집계 루트가있는 모든 다른 상태의 히스토리가 제공됩니다. 이벤트 스토어의 이벤트 (이벤트 스트림)를 이력의 날짜/시간 순서대로 읽어 집계 루트를 재구성하여 집계 루트를 재구성 할 수 있습니다 역사상 그 당시처럼 보였다.

보고 용도로 다양한 저장된 도메인 이벤트를 사용하여 매우 효율적인보기 모델을 구성 할 수 있습니다.

이벤트 소싱은 많은 작업이 될 수 있습니다. 어쩌면 많은 시간을 들이지 않으면 첫 번째 접근 방식이 가장 좋습니다. 각 방법에 장단점이 있습니다. 당신은 확실히 여가 시간에 이벤트 소싱을 조사해야합니다.

Answer 2

다시 한번 경계가 된 경계를 다시 정의하는 것이 좋습니다. 어쩌면이 역사는 다른 경계가있는 상황에서 유지되어야합니다.

CQRS을 사용하고 쓰기 모델 (집계)에서 방출 한 관련 도메인 이벤트를 수신하여 모든 집계 상태의 내역을 포함하는 특정 읽기 모델을 만들 수 있습니다.

Event sourcing은 좋지만이 상황에는 적합하지 않습니다. 엔터티 히스토리로부터 이익을 얻기에는 너무 많은 오버 헤드가 있습니다.

UPDATE

이벤트 소싱 일반 CQRS 이상의 두 가지 장점이 있습니다

1. 당신이 트랜잭션을 사용할 필요가 없습니다를
2. 그럴 수 후자는
을 원하는만큼 많은 읽기 모델을 추가

또한 큰 마이너스 :

1. 이벤트 버전

두 장점 중 하나가 응용 프로그램에서 당신을 도움이 될 경우 그것은 당신의 전화입니다.