Command Query Responsibility Separation
 Separating the writes from the reads

What?

CQRS really makes sense if your are doing event sourcing and event driven design. I will not go deep into that because it would lead us to far and admittedly I don’t have the expert knowledge yet in this domain.*

So, separating writes from reads. It means we have a database to manage the write part. Whilst the read part is derived from the write part and can be managed by one or multiple databases or / and by creating views of the data.

This allows you to use the most appropriate implementation for each model on the write and read side. ! Storing / writing data often happens in an other way than querying / reading the data! The models from the write and read side can be isolated and thus different.

When implementing CQRS it is advised to use the domain language (verbs and nouns of your domain). Don’t simply use CRUD terms but use method names like searchOrder, addItemToShoppingCart.. This is what we call using an ubiquitous language.

 

Pluses and Minuses

Benefits

• optimise read and write sides for the use case
• read side is available even if you’re write side fails
• managing security and permissions can be done separately
• design the models on read and write side to meet the needs of your domain

Disadvantages

• added complexity
• can make things a lot simpler in complex software systems, but can also make things a lot harder in easy systems
• be aware that you are not consistent but eventually consistent

 

* Event Sourcing: Ensures that all changes to application state are stored as a sequence of events. We do not store the state of an object, we store the events impacting the state of the object. When we retrieve the state, we play out these events consecutively. When doing Event Sourcing and CQRS it means persisting each event on the write part of the application. And then deriving the read part from the sequence of events.