CQRS Commands (aka the write side)

Commands are created by a client, put onto a command bus for the server to process in it's domain. Commands are simple messages/requests to mutate state. It's not about editing data, but about performing tasks. Commands are always in imperative tense (present), asking the system to do something. As they are in the imperative tense, they are essentially questions and as the language suggests, the server has the right to refuse.

Command handlers handle these commands and are simple facades/coordinators over the domain below and methods should be thin; like MVC controller actions. Behaviours should be pushed down to the domain below and not exist in the handlers themselves. As each command changes state, it also typically results in events being pushed onto an event bus for recording and processing by event handlers.

Commands and events are very similar in design, only differing by their intentions. Events are described as verbs in the past tense. As the language suggests, it has already occurred, so no point in throwing exceptions. However, you can come up with a counter event. Event handlers typically insert data into denormalised database tables in the query database (the read side) but can perform a range of other tasks, such as send an email.

CQRS Queries (aka the read side)

Commands mutate state and trigger events which describe the changes which have occurred inside the write store. It is the responsibility of the read store to subscribe to these change events and update their read store appropriately (using event handlers).

All application queries from end users are made to the read store, which can be anything from a relational database to XML files. This data store is simply a thin read layer that's heavily optimised for reads. Each application's data view (think view models in MVC), typically maps to denormalised data tables rather than using joins (which slow down queries and prohibit scaling without headaches).

That's it, in a nutshell! The read side is a lot simpler than the write side of CQRS and something developers are more accustomed to. Working with denormalised data rather than third normal form makes queries quick and very easy to maintain; something for the junior devs :)

Consistency is over rated!!!

In a CQRS system, making a write does not immediately change what is read.

This is why CQRS systems are described as offering eventual consistency. CQRS evangelists question the importance of real-time consistency. They argue that by the time end users see data it is already stale. FOr example, requesting a data object via a web app results in a series of delays before the data can be displayed to the end user and hence is to a degree stale i.e. retrieving data from the data store, populating a DTO, returning data in a web response, page rendering in a browser.

I think I agree and if this is an issue for you, I suggest you question the importance of real-time consistency for your business. I'd argue that there is a time period/delta that for which in-consistencies can be tollerated and hidden from the end users. However, I do think that efforts should be made to keep this to a minimum and perhaps this delta should be actively monitored, especially for systems where it matters (e.g. a message system with high SLAs).

Command Query Responsibility Segregation (CQRS)

We've begun working on a new project at Esendex, one that involves making use of (amongst other things) the fashionable CQRS pattern. I've been asked to head up the project and over the past week I've read a number of articles and looked at some example projects. So far, I like what I'm seeing; an architecture for developing scalable, extensible and maintainable applications. It looks promising and if proven successful could be an approach we adopt at Esendex to pre-empt any future scalability problems that could result from our continued growth.

What is CQRS?

CQRS is an evolution of command-query separation by Bertrand Meyer. It works using Domain Driven Design where the behaviour sits in the domain objects; utilising DDD means the language used is important.

As the name suggests, the CQRS pattern separates out the objects for commands (for changing application state) and objects for queries (that expose the application state). This is quite a contrast to the more typical CRUD patterns that most developers (including me!) are comfortable with. Systems typically written as one, are split into a read side and a write side.

High level CQRS diagram ('borrowed' from another blog)

Confused?!

Expect follow up posts soon, in the mean time, here's some useful links:

• Greg Young (aka CQRS God) lecture video (6 hours+ long) and accompanying notes
• Nice example CQRS implementation in C# (by... Greg Young)