CODEWITHSUNDEEP
domain-driven-design
Eduard Popescu
Eduard Popescu

Reputation: 23

Aggregate relationships in Domain Driven Design

I have a question related to relationships between aggregates in Domain Driven Design.

I have the following situation: I have an aggregate (questionnaire) which has some children (questions). The questions are entities, but because they are inside the questionnaire aggregate they can have local identities (i.e. question with id 1 in questionnaire with id 1234; I can have another question with id 1 but in another questionnaire). So to refer to a question you always have to qualify it with its parent questionnaire id.

On the other side I have another aggregate (collection campaign) which stores data (response set) for the questions in a questionnaire (the collection campaign points to the questionnaire by its id, and a response set points to a question again by its id). I can have several collection campaigns (which took place at different times perhaps) and each collection campaign stores different response sets, but for the same questionnaire (and questions).

So my question is: have I designed this well (according to DDD)? Or do I have to keep the questionnaire and questions as separate aggregates of themselves in order to refer to them from the collection campaign/response sets?

I hope this makes sense and thank you.

Upvotes: 2

Views: 1025

Answers (1)

Constantin Galbenu
Constantin Galbenu

Reputation: 17673

Ask yourself this: what are the invariants that should be protected?

In your case you must ensure that a question that is answered during a campaign exists (i.e. its index is between zero and number of question in the questionaire - 1) and its an allowed one; other invariant could be that a questionaire must not be modified after at least one question is answered; in any of these cases the campaigns must be synchronized with the questionaire. I see at least 2 solutions:

  1. The simplest solution would be to have a single big aggregate, the Questionare aggregate, with questions, campaignes and answers as sub-entities so you can protect those invariants; this has some performance implications, but only you should know is it is acceptable.

  2. The second solution would be to use a event-driven architecture like CQRS+Event Sourcing. In this case you could have separate aggregates and keep them in sync using a simple Saga that forwards some events from Questionare aggregate (like QuestionAdded, QuestionRemoved) as commands to Campaingn aggregate. I prefer this solution as better separates the responsabilities.

Upvotes: 2

Related Questions