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.

Roundup #37: .NET Core 1.x End of Life, gRPC, GraphQL, Benchmarking, Life Beyond Distributed Transactions

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.


gRPC for dotnet

We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:

– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)

We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the mananged client experience in 3.0.


Adding a GraphQL Endpoint to Your ASP.NET Core API

Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.


Introduction to Benchmarking C# Code with Benchmark .NET

Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark .NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.


Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard

Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!

Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.

In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical ASP.NET Core SignalR: Azure SignalR Service

ASP.NET Core SignalR Scaling

In this section, I’m going to cover how to deal with scaling SignalR by using the Azure SignalR Service. This is a managed service that is an alternative to using the Redis backplane that I’ve described in the previous section.

You may want to use this option as it eliminates having to manage your own Redis instance as well as dealing with a load balancers configuration of sticky sessions (client affinity). Everything is all pre-configured for you, and is a fully managed service.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

If you haven’t already, check out the prior sections of this course.

  1. Course Overview
  2. ASP.NET Core SignalR Overview
  3. Basics
  4. Server Hubs
  5. HubContext
  6. Authorization
  7. Scaling with Redis

SignalR Scaling

I’ve covered the basics of scaling in the previous section and how having a web farm poses problems when using SignalR.

If you haven’t already or are need an overview of a webfarm scenario with SignalR, check out that section which covers how to scale using Redis as a backplane.

Azure SignalR Service

First thing to do is add a new resource in Azure by and search for the SignalR Service.

As you are creating the new service, when selecting the pricing tier, note that the free tier does not support changing the unit count. Meaning you are limited to 20 connections and 20k messages/day. The standard tier gives you 1k connections per unit and 1M messages/day/unit and allows you to scale up to 100 units (depending on the region).

Once created, go to the Settings > Keys page where you will need to copy the Connection String


First, you’ll need to reference the Microsoft.Azure.SignalR package in your csproj.

From here you simply need to change the ConfigureServices() to use AddAzureSignalR() and modify the Configure() to call UseAzureSignalR()

User Secrets

Now we need to place our Azure SignalR Service connection string in user secrets. To add to our secrets via the dotnet CLI:

dotnet user-secrets set Azure:SignalR:ConnectionString "Connection String Goes Here"   

If you’re unfamiliar with user secrets, check out my blog post on handling sensitive configuration data.

That’s it. You’ll now be using the Azure SignalR Service and be able to scale to 1000’s of connections.

Get The Course!

You’ve got several options:

  1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
  2. Access the full course now by enrolling for free on Teachable.
  3. Follow along with the blog post series here on
    1. Course Overview
    2. ASP.NET Core SignalR Overview
    3. Basics
    4. Server Hubs
    5. HubContext
    6. Authorization
    7. Scaling with Redis
    8. Scaling with Azure SignalR Service

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.