From the perspective of architecture, Command Query Responsibility Segregation (CQRS in short) is a pattern relying on separation of commands (performing actions) from queries (returning data). In the simplest way, it may be implemented by segregating methods into separate classes by command-query responsibility. A more advanced solution requires two separate parts of the system handling reads and writes respectively, but having different designs, models, services and databases. The picture below presents such a CQRS implementation with separate databases, models and services:
What are the possible benefits of this segregation? In return, CQRS promises you improved performance and higher scalability.
Good and bad use cases
I have spent my Golden Card day on CQRS and here are the recommendations I found for its usage. In general, CQRS should be used only for Bounded Contexts, which really need it. You should carefully consider, for each Bounded Context independently, which approach to choose.
When to use
- It is perfect in case of a large difference between the number of reads and writes from a system (social networks being examples of such system). You can scale independently both sides e.g. you can assign more resources to read services.
- When performance is critical. With CQRS, you can optimize read and write sides independently. Also for applications, which are used by many users or need to support a lot of parallel operations on the same set of data.
- In scenarios, when you have complex business logic. CQRS may simplify understanding of domain by dividing problem into the command and query parts.
- In situations, when your UI is based on workflows and utilizes the Interface pattern. It is easier to identify user’s intents and translate them into domain events.
- If you want to parallelize the development and use two teams. One team could be assigned to read the model and second one to the write side. Please note, however, that both teams have to be deeply familiar with the CQRS pattern.
- When you already use the Event Sourcing, it combines nicely with CQRS as the write side can save current state as a set of events.
When not to use
- In case of simple user interface e.g. CRUD style.
- When you have simple business logic, then implementation of CQRS would be too overwhelming.
- Do not use it for a whole solution. You do not need CQRS for every part of a system. Focus only on this Bounded Context, which really needs CQRS.
Do you want to know more?
I am really open to discuss CQRS topics, but for those having some time in the evenings or over the weekend, I recommend blog of Udi Dahan, the CQRS specialist and free “CQRS Journey” book, where you can find case study of “Conference Management System” done by Microsoft. For those preferring to study the code, a very simple CQRS application created by Greg Young can be found on GitHub.