1
votes

I have been struggling to design aggregate roots for meeting domain.

Domain: Meeting has one or more agenda items. Each AgendaItem has a note section also each AgendaItem has one or more tasks.

Design Now based on guidelines, I am trying to keep smaller aggregate roots within meeting bounded context. so I have MeetingAggregateRoot and AgendaItemAgreegateRoot.

Business rule: Each meeting will have multiple agenda items (each agenda item may have one or more sub-agenda items). But they should be ordered by sequence and they should not have duplicate sequence.

If I keep single AR as MeetingAR with AgendaItem as Entity then MeetingAR may take responsibility for keeping AgendaItem Sequence in order. But then I have multiple tasks as well per AgendaItem so I decide to keep two separate AR as MeetingAR and AgendaItem AR (AgendaItemAR will have task entity).

Now question is... How should I design ARs so that MeetingAR is only "responsible" for meeting related actions. AgendaItemAR is only responsible for its own actions and still Sequence is maintained for all agendaitems within meeting.

Any help is appriciated on this.

1
"each agenda item may have one or more sub-agenda items" -> Is there a maximum depth of one because if not then your current design of AgendaItem --* Task would not allow for that. - plalx
only one level of sub-agenda items. - Hiten

1 Answers

0
votes

I think that it isn't a decision. If agenda items lifecycle depends on meeting, agenda would be a child entity of meeting. It would be a composition, an agenda item couldn't exist on his own.