Command Query Responsibility Segregation (CQRS)

The Command and Query Resposibility Segregation pattern first introduced/defined by Greg Young and originated from Bertrand Meyer’s Command and Query Segregation is a pattern where you separate the command and the query part of a model, which means you can use different models (objects) for reading and updating information.

Wikipedia defines this principle as

… every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects. (Wikipedia)

There can be some issues with this. Martin Fowler shows one example on the bliki with:

… Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop. (Fowler)

The datastuctures you will use in this context will therefore look different on the query side than on the command side. To serve data you can also use different datastores like NoSql databases. Sure you could use RDBMs as a datastore but some queries are more graph related like recommendation engines than others - command processing also depends on the datastructures and their needed performance. So some datastorages will therefor give you a better performance on none relational databases.

When to use and when not to use.

Here’s a short list of when to use and when not to use CQRS:

• complex models (use)
• multiuser collaborative domain (use)
• only CRUD model (not to use, it will add more complexity then it will remove)
• when consistence in writing of data is more important then consistence in quering data (use)

Since we have two datasources - one for reading and one for writing - we have to deal with synchronization of both datasources. The model that is best suited is the introduction of events, events are a well known integration pattern and offer the best mechanism for model synchronization in this context.

CQRS and bounded contexts

CQRS and DDD have a closed connection. The idea of thinking in a task based UI style while working with a domain expert and it’s UI interface centric design on those tasks. That is where CQRS comes into play and has a strong connection in DDD.

Udi Dahan recommends that code in a bounded context should not be querying data from other bounded context models specifically when it comes to command processing. This has to do with the nature of the consistence part of the command which could - if you try to - read data from an outdated data source which then would led to inconsistent data on the command part. So it’s about consistency and second it comes to the single responsibility principle. If implemented correctly there should be no need to query data from a command side to other bounded contexts. If you still need to propagate data from one bounded context to another one should consider to implement the publish subscribe pattern as a suggestion.

If you take the latter pattern into consideration then think about the validity the data has in a given range of time. For example think of a special subscription, lets say a one year subscription of a membership.

Event sourcing

Greg Young is the expert here. Event sourcing is a style of implementing business logic as well as data persistence. An event in terms of code is simply a data holding structure and a style of recording an action that had occured.

The idea is to store the events or a series of events that brought a system in a state where it actually is. This is perfect in case you need auditing or some kind of journaling. So you actually store the history of the system. To restore a system you have to apply all the events from the beginning up to the last event to get the last state of the system. In most cases you will implement some kind of snapshot capability to shorten this process. If your domain is highly time dependent and history driven then CQRS and Event-sourcing is a good choice. In the latter type of model the CRUD-style isn’t appropriate.

One thing should be mentioned - there is no delete in event sourcing! I mean you can delete if this is modeled as an additional event but since this kind of storage is only additive you can still see what has happened before the ‚delete‘.

More information can be found on Greg Youngs and Udi Dahans blogs. There is also a clarification article as a pdf on CQRS which can be found on Udis blog.

[Greg Youngs info page on CQRS]