1

I have an aggregate, let's call it Party. For a party, I can have many People which is an aggregate as well as they can exist on their own without the Party. But specifically for the Party , I want to keep track of how much Food was eaten by each person.

How can I model this? The Food cannot exist without the People at the Party so I don't consider this a separate aggregate. Food has items inside it.

I have modelled Party as follows:

{ partyId: number people: [ { peopleId: number food: { sausages: 2 burgers: 5 } } ] }

Is this the correct way to model the data?

If I want to get the details for one person at a Party, how would I model the method? Is it a case of having a repository method to get a party by its id and then filtering the People array by the id of the person I want?

I have modelled the data but it doesn't feel quite right to me.

Edit:

Thanks to one of the answers, I have changed the Party aggregate to be:

{ id: number participants: [ { personId: number food: { kind: string quantity: number } } ] }

The People aggregate has been renamed Person:

{ id: number name: string }

This better communicates the relationship and I think is easier to understand.

Improve this question
1
  • As long as you reference the other aggregate with its Id, it's generally fine. Avoid nesting whole aggregates. Commented Feb 2, 2024 at 14:13

2 Answers 2

Reset to default
1

Considering that:

  • the people member seems to be a list of "decorated" peopleId references and not a list of people entities (which would require to duplicate people participating to several parties)
  • the food sub-member member is a collection of value objects (i.e. having no identity and solely identified by the kind of food and the quantities consumed in the enclosing party)

this design is perfectly fine and compliant with DDD principles.

In fact, the people member implements a many to many association between party and people. I'd recommend to rename it Participants, to avoid the ambiguity with People entities. And the food appears to implement an association class:

enter image description here

Improve this answer
5
  • Thank you for your kind response. I am a touch confused about your diagram, if Participants should replace People why are they both on the diagram? If I am correct that Participants should replace People, is it not a one to-many relationship, as it's many people at one party? And then a one-to-many relationship for Participants to PartyFood as it's one participant to many items of food? Commented Feb 2, 2024 at 11:22
  • Good question: in the diagram, participant represents a people participating to a party. peope is the people, independently of any party. This what I meant with the first bullet. If in your model, the people (including all atributes, like name address, etc) would be embedded in the party, it would no longer be ddd compliant, as you would include one aggregate into another and aggregates would not have the independence they require. Commented Feb 2, 2024 at 12:26
  • I think People is the wrong name in this case. The object seems to represent a single person, not a group of people. Commented Feb 2, 2024 at 14:11
  • Thank you @Christophe. So what about this for Party: { id: number; participants: [{ id: number; personId: number; food: [ { kind: string } ] }] } Then I would have a seperate Person aggregate, replacing People. Commented Feb 2, 2024 at 22:20
  • Yes, that's the idea (with quantity:number behind kind ;-) ) . Commented Feb 2, 2024 at 23:42
1

Thanks to one of the other answers (https://softwareengineering.stackexchange.com/a/450854/266614), I have changed the Party aggregate to be:

{ id: number participants: [ { personId: number food: { kind: string quantity: number } } ] }

The People aggregate has been renamed Person:

{ id: number name: string }

This better communicates the relationship and I think is easier to understand.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.