Let’s say I am modeling a music event system.
I have:
- music events
- listing events (the items in a lineup) – a listing event has acts (the artists playing in an item in the lineup – these can be collaborations)
- artists (the artists that make up an act)
If I were to say that each of these were an AR – they indeed have identity.
When loading my music event AR would that mean that in order to work with the listing events within it they should be value objects?
When loading a listing event – let aside it may be a value object because I need to load it by itself – I want to modify the acts within that listing event – does that mean the acts need to be value objects?
I can’t have this as one massive tree
- a) some of these events are huuuuuge
- b) artists play at many events – I don’t think I want that data duplicated do i? Or do i? that might be ok… hmmm
What’s the thinking here? how should this be modeled? Indeed – (and I know it’s naughty to think about this) how would such a huge tree be persisted in something like Postgres? if I blob all the value data I lose the ability to query that data… So it’s in my interests to have this data in tables where it is index-able.
I don’t want to go the full CQRS/ES route with read models for querying. How can I best handle this inter-related data in a DDD manner?
1
Here,
MusicEvent is the can have many EventListings
each EventListing could have multiple EventListingArtists
However the EventListingArtist is linked to Artist as a reference
When it comes to persisting, this should be good enough for your requirement, even if you have an event with large number of listings. Only trick is to use optimized queries when fetching data.
2