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?

  • There are hundreds of ways of modelling this depending on the use cases and domain rules. What are things that will change together ? What are some domain invariants ? DDD is good for complex domains, what makes that domain more than a bunch of data containers ? You seem to put CQRS aside but if all your complexity resides in querying a lot of data and the rest is CRUD, it may well be CQRS you need instead of DDD. – guillaume31 Jan 26 '16 at 14:21

Following UML is a one possible design 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.

| improve this answer | |
  • 1
    Could you please explain the reason why there is negative feedback, If the reason is not described there is no way to improve the answer. Thanks – Low Flying Pelican Jan 19 '15 at 11:33
  • I didn't downvote - I hate it when people do that without explanation – iwayneo Feb 11 '15 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.