The Developer Day | Staying Curious



What is CQRS?

CQRS is a software architecture pattern which stands for Command Query Responsibility Segregation. The author of the pattern name CQRS is Greg Young who first described it in his blog:

I am going to throw out a quick pattern name for this and call it Command and Query Responsibility Segregation or CQRS as we are in fact simply taking what would usually be one object and splitting its responsibilities into two objects.

At the time of writing CQRS does not have an official definition. It’s difficult to define CQRS with a definition that would be both simple and useful. To describe CQRS at an object level I’ve came up with a definition which is just a reworded sentence from Greg Young’s blog post:

Command Query Responsibility Segregation or CQRS is the creation of two objects where there was previously one. The separation occurs based upon whether the methods are a command or a query.

CQRS can also be defined at a higher level. Greg Young was kind to provide a definition:

Command Query Responsibility Segregation or CQRS is the recognition that there are differing architectural properties when looking at the paths for reads and writes of a system. CQRS allows the specialization of the paths to better provide an optimal solution.

CQRS pattern is similar to CQS by Meyer but is also different. CQS separates command methods that change state from query methods that read state. CQRS goes further and separates the command methods that change state and query methods that read into two different objects.

Benefits of CQRS

  • The most simple benefit of CQRS is that it simplifies read and write models by separating them. Write model no longer contains queries and developers can directly focus on domain model behaviours. What otherwise could have been a repository with hundreds of different read methods mixed with different lazy loading, pre-fetch and paging strategies can now be hidden away in a separate read model.
  • Another reason is Divergent Change. Divergent change occurs when one class is commonly changed in different ways for different reasons. You might be modifying queries more often than commands which might not only break your read queries but your commands as well. By having them separated you minimise the risks of both being broken.
  • The single most important benefit of CQRS is that by separating read and write models you can make different choices on different models. For example you may optimize your write model for write performance and your read system for read performance.
  • Another nice feature of CQRS is the available option to easily distribute work across separate teams. For example the read part of a web e-shop application can be outsourced to less expensive developers offshore.
  • Event sourcing is a different pattern which shares a strong symbiotic relation with CQRS. Once your system reaches an architectural level where you may need multiple data models it might and probably will introduce synchronization issues. It is then impossible to say which model is incorrect. In an event centric system where commands are translated into events by the domain model these events can be used as the primary data model. This not only solves data synchronization issues, but also significantly improves testing by allowing to test for “what didn’t happen” and opens easy doors for integration with other systems since other systems can now listen to the events published by the domain model.
  • Eventual Consistency. In very simple terms Eventual Consistency can be defined as simply just caching. In event centric systems it is possible to delay the handling of published domain model events and handle them in a different thread or a process. This will make write and read data models inconsistent but it might significantly improve the performance of your commands.

In Conclusion

CQRS is a very interesting pattern. By some it may even be considered to be the silver bullet. It isn’t. Like all patterns CQRS has tradeoffs. It may be difficult to sell CQRS to management since it’s not a well known classic approach to software architecture. Less known tools, technologies. As an example in the PHP world there are currently no mature service buses such as NServiceBus in the .NET world. It is almost impossible or more often than not worth the Return of Investment to migrate legacy apps to CQRS.

RSS Feed

3 Comments for What is CQRS?

hakre | July 20, 2010 at 2:00 AM

Thanks for pointing to this. It’s nice input to think about the more general stuff.

CQRS Resources - The Developer Day | July 21, 2010 at 9:36 PM

[...] the past I wrote about what CQRS is and now I am adding a list of available CQRS resources known to me. If you come by any other CQRS [...]

Keith Pope | November 20, 2010 at 6:12 PM

Good to see CQRS mentioned in a PHP context, I think with the push to MVC the modelling/architecture side of things is getting more important.

I would slightly disagree that CQRS could not help with legacy apps, you may find you have reached a barrier with scalability of one of your app tiers, for instance the ORM, it may then make sense to migrate these so you can scale more easily.

I think one of the great things about CQRS is that you can pick and choose the parts you need, I suppose this is integral to its DDD roots :)

Also as we are using dynamic languages generally in a web environment we may not need an ESB like NServiceBus, I have seen examples of atom feeds (currently researching) being used as the bus. You can then use pubsubhubbub to handle the routing and atompub for service discovery.

I have created a really simple CQRS in PHP here:

Leave a comment!



Find it!

Theme Design by