Is CQRS Complicated?

There are many misconceptions about CQRS. It’s often referenced alongside other patterns that can make it seem difficult and complicated. Is CQRS complicated? No. CQRS is simple. Really simple.

What is CQRS?

First, let’s tackle at the very core what CQRS actually is.

CQRS stands for Command Query Responsibility Segregation and was coined by Greg Young. CQRS is related to CQS (Command Query Separation) principle by Bertrand Myer which states:

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, a command is a method that mutates state and query is a method that returns state. A method generally doesn’t do both, but there are exceptions to this rule.

CQRS takes CQS a step further by separating commands and queries into different objects.

To use an exampling in C#, here is a shipment class has two methods. It applies CQS, in that each method either performs an action or returns data.

CQRS Applied

If we take the above class and were to apply CQRS, we simply just need to turn this into two objects. One object would be used for mutating state (ShipmentCommand) and the other object for returning state (ShipmentQuery).

That’s it. You’ve just applied CQRS. Wasn’t that totally unexciting?


I suspect the reason for the misconceptions about being complex and difficult stems from people seeing a diagram like this:

Is CQRS Complicated?

If you search google images for CQRS, you are bound to find almost every diagram that looks like the one above or some variation of it.

Is the diagram applying CQRS? Yes.
Is the diagram only applying CQRS? No.

When you hear talks or read about CQRS you are often also hearing about a bunch of other patterns or technology. Mainly those that in attempted to be represented in the diagram above.

You do not need:

  • Message Broker or Bus
  • Messaging
  • Domain Model
  • Domain Events
  • Event Sourcing
  • Eventual Consistency
  • Separate Models for Reads and Writes
  • Domain Driven Design


I often say that CQRS is an enabler. It enables or facilitates using other patterns that often fit well together. This is why you often see CQRS and Event Sourcing applied together.

CQRS is not Event Sourcing nor does it require you to use Event Sourcing. CQRS simply fits well and enables you to apply Event Sourcing.

Fat Controller CQRS Diet

I’ve blogged a bit about how to implement CQRS without any of the other fluff. You can check out my Fat Controller CQRS Diet blog series as well as a related talk:


I plan on breaking down some of the misconceptions and other aspects that are often lumped in with CQRS in coming posts.

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Orleans Smart Cache Pattern

Orleans Smart Cache PatternI discovered the Orleans Smart Cache Pattern by listening to a talk by John Azariah and Sergey Bykov.  The idea is that you can use Orleans as a distributed cache in front of (permanent) storage.  This is really ideal if you have a read heavy system, which most are.  You could optionally also choose to buffer your writes when you make state changes.  Ultimately you will reduce load on your storage by accessing data/state from memory.

Blog Post Series:

Video Tutorial


State Holder Grain

The idea is we are going to create a Grain that will be used for holding/containing our state.  There are just two methods, setting and getting our state as defined in IStateHolderGrain<T>


For this example, I’m creating a POCO CustomerState to hold some customer data. Then create a ICustomerGrain that just extends IStateHolderGrain where T is our POCO CustomerState. Our concrete class CustomerGrain that implements that new ICustomerGrain. Lastly I created a CustomerStateService which just contains some static methods that create and retrieve our POCO.


As per my previous post, I’m using ASP.NET Core with Botwin Middleware for a route endpoint.  From here I can use the CustomerStateService to create and fetch out our data.


One of the benefits is abstraction as we can have a POCO for our state that can be persisted to permanent storage.  There’s no dependency of Orleans in our POCO or Botwin Module. Also we have an immediate consistent cache.  If we were to expose methods to modify the state, our grain would persist those to permanent storage when it decides and we are always returning the most up to date state.


If you want to try the demo, all the source is available on my PracticalOrleans GitHub Repo. Do you have any questions or comments? Are you using Orleans?  I’d love to hear about it in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Mediator between Integration Boundaries

Integration BoundariesIf you have followed my Fat Controller CQRS Diet series, you will see that I use the mediator pattern.

More specifically I use MediatR library in all the code examples.

I recently gave a talk at CodeMash 2017 with the same title.   It went a bit more in depth about why and where I use the mediator pattern.

Integration Boundary

I want to decouple my application from the framework I’m using. The mediator pattern is one way of achieving that.

My code should be be my code.  Not littered through framework code.

Generally, I don’t want to have any dependencies on MVC, Web API, WFP, WinForm or whatever the top layer framework is that I’m using.

If I’m using ASP.NET MVC or Web API as my frontend to expose my application, I want to leverage it for what it’s good at.  The various aspects of the framework such as routing, view rendering, serialization (possibly) but without coupling my code to those.

Context is King

I generally don’t think in black or white when it comes to developing software.  Context is always king.

Making decisions around context is really important.

How do you know if you should decouple yourself from your framework?


Are you creating an application that is likely going to be used for many many years?

Does it have high value to it’s users?

Is it only throw away to validate an idea and going to last 6 months?

How large is the application, in terms of length of time to develop?  Could you rewrite it quickly?

Are you developing an application with a web interface or are you developing a web application?


All these questions and many more really matter in determining how far you should decouple from your web framework.

I love hearing your comments, questions and feedback!  Please post a comments or on Twitter.