CQRS Read Model Design when Event Sourcing with a Parent-Child-GrandChild… relationship

Question

I\'m in the process of writing my first CQRS application, let\'s say my system dispatches the following commands:

• CreateContingent (Id, Name)
• CreateTeam (

Answer 1

What you're probably going to end up with is a combination of 1 and 2. There is absolutely no problem with enhancing or enriching events to have more information in them. It is actually quite helpful.

• What if a future subscriber to the event needs even more info? I can't add it!

You can add it to the events going forward. If you need historical data you'll have to find it somewhere else. You can't build events with all the data in the world on them just on the off chance that you'll need it in the future. It is even allowable to go back and add more data to your historical events. Some people would frown on this as rewriting history but you're not, you're simply enhancing history. As long as you don't change the existing data you should be fine.

I suspect that your event handlers are also going to need to subscribe to more events as time continues. For instance are teams going to need to be renamed? If so then you'll need to handle that event. Don't be afraid to have multiple copies of the same data in different read views. Coming from a relational database background this duplication of data is one of the hardest things to get use to.

In the end be pragmatic. If you're encountering pain in applying CQRS then change how you're applying it.