06:Command Query Request Segregation (CQRS)

Thursday, 26 August 2010

A colleague presented a suggested pattern that he would like to employ on a project that is being tendered for. Having only glanced at this pattern in the past I did some quick research and came across an Article by Udi Dahan entitled “Clarified CQRS”.

This was an excellent article where he goes into the detail and the possibilities that CQRS offers.

In short, CQRS offers a solution for almost all the general problems associated with creating enterprise level solutions. To name a few:

1. Performance: Performance is made possible by the fact that the Readable and Writable Data objects are separated. I.E. you read from a specialised copy of the data (The specialised data is a formatted piece of the actual data which represents the specific view where it will be displayed in), and you write to another data repository, or sets of repositories.
2. Scalability: Scalability is achieved because every object is the smallest useful object that makes up part of the solution. Due to the fact that this object can then independently exist and therefore scaled in means that you could scale at the most granular level.
3. Information Synchronisation: Because commands are then separated out into a subscriber-type model, you could update not only your reader data store but any number of other potential repositories.

Udi goes into allot more detail in his article which I would suggest reading it.

He does however not go into the potential pitfalls of this pattern much. During my research I also came across a post/article by Garry Shutler entitled “CQRS: Crack for architecture addicts” where he becomes quite animated about the realities of CQRS if it is not considered carefully.

Although Garry's article is very funny and honest it should be taken very seriously. CQRS is often a very complex implementation. Because CQRS is not big on reuse (which as Udi states is often a fallacy anyway) every single piece (Think field/object/operation) of the solution becomes a distinct separate piece of work to be done.

To truly support scalability and synchronisation, every single one of those components may require a queuing mechanism or some type of communication buss. Think about the project you have worked on where you had 250 projects in a single solution. With CQRS I can see that multiplying by a couple of factors, and each of them potentially needing a distributed transactional MSMQ created. With multiple data sources the effort again multiplies. Etc.ect.

I’m not saying SQRS is a bad pattern, but as with all patterns you should be very careful in deciding on a pattern before you try to implement it. Make sure everyone on your team knows and understands it. In the case of CQRS this would include the business Analysts, your client and the end-user representatives (due to the different approach to the UI CQRS would suggest).

Take Garry’s advice very seriously. CQRS has a place, but it probably is not the solution for you.