CQRS stands for Command Query Responsibility Segregation. I believe it to be a great architectural pattern that has at its core a couple of main concepts:
- Asynchronous: Your data is stale the moment you read it from your storage. Come to peace with this and treat your system as asynchronous.
- Separation between the update model (Command) and the read model (Query): A very powerful thought that allows you to have multiple, customised models for the specific task at hand. More on this later.
- It fits really well with Event Sourcing and Aggregates: Not part of CQRS, but honestly, it’s a match made in heaven.
I started to write an article explaining it, but then realised that I was replicating some great articles that already exist and that I encourage you to go and have a read:
- A concise explanation of CQRS by Martin Fowler
- If you have the time, have a look at this PDF called: “CQRS Documents by Greg Young”
- This good CQRS article by Microsoft Press
Maintainability, the hidden gem of CQRS
Many of the articles on CQRS talk about what it is, how it works, and some of its benefits. Still, the learning curve is not trivial. CQRS ia a pattern that doesn’t lend itself nicely for a simple Hello World demo app. When used together with Event Sourcing, it seems that the amount of boilerplate necessary for a simple application is baffling.
It is when the complexity of the system increases that this pattern turns into a real asset, and particularly the way it allows you to evolve your system and change requirements as time goes by. This is what I normally refer to as
Functional Scalability: The capacity of a system to accommodate new functionality by maintaining complexity at bay.
Don’t be fooled, there’s no free lunch and spaghetti code can be done in any language and pattern. But what I claim is that the design constructs used on CQRS-based apps make it easier to think about your domain appropriately and control complexity.
Properly grasping the benefits of CQRS
This is why I’ve thought of exemplifying it’s biggest benefit (Functional Scalability) through a series of articles that narrate the evolution of a piece of software. I’ll show how it would evolve on a typical MVC/CRUD-like app vs a CQRS one.
The application I’ll use to exemplify this difference is a simple classifieds site. It seems only fitting that after working all these years in this domain I use it as the example. Don’t worry, won’t give away any trade secrets.
For the CQRS version of the app, I’ll use a new framework I’ve been working on that I’ve called CQBack. More on the framework soon.
Hope you find it enjoyable.