CQRS: Really simple real life benefit

I got this real life question once again just recently:

“Could you show the name of the person who created each order in the list as well?” (domain changed to protect the innocent)

This question is a very basic, but very real, example of why I like the Command Query Responsibility Segregation (or CQRS) pattern.

With a datamodel that looks like the one above, the technical answer is usualy someting like: “Ok, how are we going to do this? Let’s put in a join to the User table. Then lets extend the order object with a display property (!!!) for the users name”. If the team is a little more trained you might hear something more along the lines of: “Ok so we’ll just specify in the query that the object mapper should load the user that’s associated with each order as well”. One is a little cleaner then the other, but both will most likely start to smell pretty quickly. Then somebody comes along and asks for a count of the items on each order and before you know it, your “FetchAllOrders” sql has balooned into some kind of monster join that no one but it’s mother can love (or figure out) and as an added bonus, performance goes south.

In a CQRS environment we have the priveledge of designing solutions like: “Sure, lets just store the user name in the viewmodel for the order list screen so it will be right there for clients to display. Also to make sure it’s kept up to date if it changes, let’s subscribe to the “UserRenamed” event.”.

And for the item count? Just subscribe to the “ItemAddedToOrder” and “ItemRemovedFromOrder” events and update “NumberOfItems” accordingly.

It just makes me feel all warm inside.

Tags: cqrs, example, real life benifit, requirements, Software Architecture