CODEWITHSUNDEEP
domain-driven-design
msmani
msmani

Reputation: 720

DDD for a domain having composite relationship

Assume that I have two aggregates e.g. Document and Binder. A Document could be standalone so we have modeled it as an Aggregate and in similar way we modeled Binder also an aggregate. Now the problem is that a Document could be inside a Binder as well, now how to model this scenario. When a Document is inside a Binder to work on the Document we may have to check some invariant related to Binder before allowing the user to work on the Document.

One way I could think of is having two model

  1. Document (an Aggregate)
  2. BoundedDocument (an Entity inside Binder Aggregate)

Is there a better way to model this scenario.

Upvotes: 0

Views: 162

Answers (1)

Constantin Galbenu
Constantin Galbenu

Reputation: 17703

From what I understand you should have two separate Aggregates, Document and Binder, and use a Saga (Process manager) to eventually bring the entire system in a valid state. In other words, you should model the modification of a binded document as a business process.

This Saga would be started with all the informations regarding the modification of the document (i.e. all the modified properties in the document) then it would send a command to the Binder that would check its own invariant and if all is OK then it would send the update command to the Document aggregate. It should also react to all the events that could bring the system to an invalid state, i.e. events generated by the Binder Aggregate because there is the possibility that the documents in the binder enter in an invalid state because of the Binder Aggregate mutation.

A different architecture would be to send the update command directly to the Document Aggregate, without checking the invariant. Then, the Saga would react to the document update events by sending a command to the Binder Aggregate. If the Binder says that it is not OK then the Saga would send compensating commands to the binded Document. This design would be more permissive with invalid documents but it is simpler.

Both the designs would eventually bring the system in a valid state but the first would minimize the times that an invalid document exists at the cost of increased complexity because the Saga would need to be started and would store the document modification information.

The alternative is that you create a new nested-entity inside the Binder Aggregate, namely the BindedDocument but this entity doesn't seem to be conceptually different from the Document Aggregate. This is reflected by the code duplication that you would have.

Upvotes: 1

Related Questions