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?

Misconceptions

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

Enabler

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:

More

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.

eShopOnContainers a Microservice based .NET Core Sample Application

eShopOnContainersFinding good sample applications if pretty difficult, if not impossible.  Most are small Todo style applications that are generally very CRUD based.  Thankfully Microsoft has created the eShopOnContainers a Microservice based .NET Core Sample Application.
.NET Core reference application, powered by Microsoft, based on a simplified microservices architecture and Docker containers. This reference application is cross-platform at the server and client side, thanks to .NET Core services capable of running on Linux or Windows containers depending on your Docker host, and to Xamarin for mobile apps running on Android, iOS or Windows/UWP plus any browser for the client web apps. The architecture proposes a microservice oriented architecture implementation with multiple autonomous microservices (each one owning its own data/db) and implementing different approaches within each microservice (simple CRUD vs. DDD/CQRS patterns) using Http as the communication protocol between the client apps and the microservices and supports asynchronous communication for data updates propagation across multiple services based on Integration Events and an Event Bus (a light message broker, to choose between RabbitMQ or Azure Service Bus, underneath) plus other features defined at the roadmap.

eShopOnContainers

Here’s a development environment overview of the of the eShopOnContainers app.  I just want to point out a few pieces that I thought were well done in this sample. eShopOnContainers  

Service Autonomy

Each service (Identity, Catalog, Ordering, Basket, Marketing, Locations) is autonomous.  It owns its own data(store) and does not have any dependencies on any other services.  In order to communicate with other services, it uses an event-driven model via publish/subscriber on an event bus of RabbitMQ or Azure Service Bus. Each service does contain its own HTTP API that provides functionality such as retrieving data as well as performing specific actions.  For example, the Ordering service contains an API project that has HTTP resources for retrieving orders as well as canceling an order.

View Composition

Since each service provides its own HTTP API for retrieving specific data owned within that service, you ultimately need to compose your view from multiple services. Backend-For-Frontends (BFF) patterns are used to provide a single API backend for a specific client type.  For example, the MVC and SPA apps use the Web-Shipping and Web-Marketing BFF while the Xamarin mobile app uses the Mobile-Shopping and Mobile-Marketing BFF.  Ultimately these BFF make HTTP calls to the needed services to compose the data required for the client.

More

I highly recommend checking out the application and digging in a bit.  There are many different services and each has its own individual architecture within it.  Such as the Ordering service using CQRS via the MediatR library in it’s HTTP API.  It also uses some technical DDD patterns as well. If you’re interested in the Backends-For-Frontends, I recommend checking the post by Sam Newman and Chris Richardson. Although a tad outdated, Particular have also a fork of eShopOnContainers but modified to run on top of NServiceBus. If you know of any other solid sample applications beyond To Do lists, please let me know in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Find MediatR Requests without Handlers

Find MediatR Requests with no HandlersYou’ve run into it.  MediatR throwing an InvalidOperationException when you didn’t have a matching handler for a request.   There’s a fairly simple solution to prevent this: Find MediatR Requests without Handlers.

So here’s some quick code you can throw in a unit test to verify you don’t have any missing handlers.

Find MediatR Requests without Handlers

The above code uses reflection to get all the IRequest<>, RequestHandler<> and RequestHandler<,>.  Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.

Usage

Here’s a quick unit test that shows it’s usage for finding Requests without any handlers.  In the sample below I have two Requests without Handlers: MyRequestWithoutHandler and MyRequestWithResultWithoutHandler

Source

All the source code for my example is available on GitHub if you want to try it yourself.

Another useful test would be to verify that your container actually has the the request and behavior handlers registered correctly.  Another post to come with that.

Always love hearing your comments.  Please post them here or on Twitter.