CODEWITHSUNDEEP
domain-driven-designaggregateroot
Mosh
Mosh

Reputation: 6044

DDD: Question about Aggregate boundaries

I have a complicated scenario in which two aggregate boundaries sort of contradict each other.

I have 2 Entities: Request and Mission. User creates Requests and later on he can create Missions and assign existing Requests to a Mission.

Requests and Missions can be created independently. In other words, I don't need to have a Mission when creating a Request and vice versa.

So I'm assuming we have 2 different Aggregates here: Request Aggregate and Mission Aggregate, with each Entity being the root of its own Aggregate.

HOWEVER, we have an invariant that violates this assumption: You can Postpone or Cancel a Mission, which causes the Status of all Requests assigned to it to be updated accordingly.

How can I enforce this constraint if Request and Mission are in two different Aggregates? If I put them in the same Aggregate, it's not possible to tell who is the Aggregate Root because each Entity can be created independently.

Any advice?

Mosh

Upvotes: 0

Views: 472

Answers (2)

TheMar
TheMar

Reputation: 1964

my suggestion would be that to use eventing pattern. When one Agreegate's state is changes publish event. This can be consumed in handler which will have ability to change other Aggregates state. Hope it makes sense.

Upvotes: 1

Vijay Patel
Vijay Patel

Reputation: 17522

You're on the right tracks already. The piece you're missing is this: Aggregates can contain other aggregates.

It's OK for your Mission to trigger Status changes on any Requests that it contains.

Upvotes: 1

Related Questions