CQRS – First step – Split to commands and queries

Currently, I am working on lightning talk how to introduce CQRS to your project. I thought that would be good to explain this topic further for people who won’t be attending my presentation.

I will write about:

  1. splitting code to commands and queries
  2. introducing simple read model
  3. creating read model synchronously
  4. creating read model asynchronously with SignalR notification

Stay tuned 😉

Recent state of your app

Let’s assume that you work on an e-commerce platform. You got plenty of controllers, services and repositories in your project. Every controller use services, services use other services, multiple repositories, validators and helpers. Dependency level increase time and effort to find correlations between components and context in your application.

You think that system that will advantage from introducing CQRS but you find it too overwhelming and hard to implement in the current situation. On the other hand, you feel that multiple parts of your codebase are painfully difficult to understand and you want to do something with that. You would like to implement this pattern step by step, without hard breakings in your current code.

You find first weak spot – product management. Your products contain dynamic fields, with own validation for every defined field. Moreover fields are bound to categories so we cannot add a field value to a product that is not corresponding to a product category. At the beginning of the project you followed this article about creating and validating a dynamic model which resulted with such structure:

These models are heavily used by ProductsService – mainly consumer of logic from ProductsController. In this place, you want to start your focus. Below there is a simplified view of this service, with only 2 actions listed:

  • GetProducts – returns products for product’s grid
  • ChangeProductFieldValue – sets value for specific product’s field

As you can see, only these 2 methods have already created a case for injecting 4 different dependencies. 100 lines of code for merely 2 requests, when this service needs to handle a lot of them. With more internal logic your service will start looking similar to nopCommerce‘s one – ProductService.cs. Furthermore, every change or enhancement in a request to the ProductController has to be reflected with a modifying behaviour of this service – it will lead to increasing of complexity, impeding writing and maintaining unit tests and prevent this service from future refactors.

Your ProductService demands some action.

Command and queries

CQRS is a simple pattern – two objects for command/queries where once there was one.

This quote is from Jimmy Bogard post which teaches you how easy is first step in your application to introduce first elements of CQRS.

Jimmy created awesome library called MediatR which provides an in-process messaging component to your system. It extremely simplifies process of sending command and queries and responding to them – you don’t need to created your own class structure, everything is given out-of-the-box.

In previous code you structure GetProductsQuery and ChangeProductCategoryCommand, both implement IRequest interface.

As parameter type you need to define what is the type of the returned element, after handling request – as you can see command is returning nothing but the query is returning a list.

Then you define handlers of these requests – they need to implement IRequestHandler interface, with query / command as parameter type.

Finally, you change your ProductController to publish messages by the injected mediator:

And this is it – you went your first step in CQRS journey. Command and query are defined in different files which can be treated separately with different approach about database querying, parameters validation and internal logic.

The advantage from this step:

Moving from typical layered pattern to Command/Query one, without further actions, has several advantages:

  • Concern on Single Responsibility Principle – one class which handles a request.
  • Clearly defined target and dependencies.
  • Avoidance of mixing code which modifies data and returns it.
  • Deeper view of your system – finding a correlation between handlers, not layers.
  • Less effort in maintenance and more detailed refactoring.
  • Ease of writing unit tests.

In our case, such change gave us a better understanding of our system and possibility to move toward more complicated solutions.

The moment of denying

Wait, but you have seen in the internet piles of articles and videos how people running their CQRS app with event sourcing, multiple databases, message queues etc. Complicated diagrams, layers, components, arrors from one way to another…

You don’t need it. Not at the beginning.

In the simplest form, CQRS model don’t need to be treated as a different database model but as different in and out objects. Splitting model to the separate storages gives a lot of value, but maintenance of a distributed system with eventual consistency model is definitely tougher that a monolit’s one with a single processed request.

Just remember that nobody introduced this pattern to an existing application, with so many components, in one day. Focus on a single thing, refactor your logic into separated command and queries, and then go further for greater good. Such splitting to simple handlers, won’t break your application and you will get a better insight of how your system is working. Then you can take next step.

  • You don’t even need read models or objects. Treat the event stream as something you can query to get going asap.

    • Radosław Maziarka

      I think that for a lot of people event stream design can be more difficult to approach that typical object’s one.