One of the most liberating things about the CQRS ES way, is the simplicity of the read side. However, if you are new to CQRS you may have wondered how it works. How for example, would it work for a classic master details view? You are not alone, in fact, I am writing this post in answer to exactly this question I found on stackoverflow:
“So my question is how are people handling a screen where by for example it displays a summary of customer details and then a list of their orders with a [more detail] link etc….”
If your interested you can find the question and it’s replies here: http://stackoverflow.com/questions/2273796/cqrs-the-query-side
Defining the data we will need in the Master Details view
For this example lets assume we need to display a screen with a customers details, a balance of the amount they have spent and their last 10 orders with a more link to view the rest. In a traditional CRUD style system we would need to join data from the clients table, orders table and sum the order value to get a total value. In contrast, in a CQRS ES based system we could simply get the customer summary by customer id which would already contain all the required data (and no more).
So how would we achieve this simplicity (and performance)?
De-normalising the Event Stream is the key to Read Model Simplicity and Performance
Within a typical CQRS ES application the de-normalisers react to events raised to create the read model. So given the following set of events:Then lets assume the customer makes multiple orders. The event stream would look something like this:Our de-normaliser can then be set to react to those events in order to generate a data transfer object/view model:
Due to the steep learning curve associated with CQRS and ES many developers (wrongly IMHO) have the view that it is a complex approach to development. I hope this example shows how for the read side particularly your job as a developer is greatly simplified.