Introduction to CQRS

The time has come to discuss the CQRS which has recently become loud recently mainly by the man who is called Udi Dahan. This cool guy came up with this approach and praise him for it.


Admission

I stated that I would do something about CQRS on this blog, recently there has been a lot of talk about this pattern, also a lot of concepts related to this pattern, such as NoSQL, DDD or event sourcing, and later all the material will be created, but for now I will focus on CQRS.


Normal model

As the title of the subsection shows, first I will compare these two concepts and then you will decide if CQRS makes sense.

The usual model looks like this:

So there is a customer and one model. The client sends queries, the model returns the answer. Usually it looks like this.

The problem with this is that all logic is in one model, the logic of which is not separated in a special way, and then the result is such jokes that it cannot be tested or developed in a meaningful way, or debugging it is a slaughterhouse.

It also dependes how who writes this model, but as usually everything is in one model there is mixed up with tangled …

There is a way to solve this and CQRS is the solution.


CQRS approach

Whereas in CQRS it looks like this:

This image has an empty alt attribute; its file name is ext_020196117736395-1024x564.png

What is this supposed to be? The model is split into two sides for reading and writing. On the write side, all commands are for write database operations . It is also good to note that CQRS has two defined read and write databases.

In the database for writing there are all the most important data, they are important because if something changes there (as shown in the diagram above) an event is sent, that something has happened in the system and this event is saved to the readable database, it can be said that the readable database is something similar to cache and is associated with event sourcing (about event sourcing and the database as a cache later).

And CQRS in more detail divided into specific classes looks like this:

So, the inquiry goes from the read page and after a short time we receive the answer, the implementation method on the read side is optional, it is quite simple.

On the write side we send a command that goes to the CommandBus. The CommandBus class is used to assign the appropriate commands to the appropriate classes that support them, i.e. handlers of these classes, and each command can have only one handler.

Then, after handling these commands, we save the data in the database and in the repository and change our logic, the so-called Domain object, which is our business logic in short. The term Domain object comes from DDD, but about DDD I we will talk later.

Then, when the operation is over with all these data, we send an event to EventBus, which assigns the appropriate events to the appropriate handlers of these events and saves the changes to the database.

Question for one hundred points. Do you know what this lady has to do with CQRS?

Maybe you guessed … Yes, he writes and reads data, you can see that he has been using CQRS successfully for years 🙂 But that is the whole concept of CQRS in a nutshell.

As I mentioned, I have presentations about CQRS soon and there I prepared a practical example of a prototype banking system using CQRS in connection with event sourcing. In the next article I will go specifically to the code and I will mention about Microsoft’s MSServer database, because I used this database for this project.

Later, when I describe this project, it is worth connecting the read and write page together with the dependency injection container to wire all everything nicely, register all classes in the system.

Asynchrony can also be used in CQRS. In the implementation details, people argue that CQRS without asynchrony makes no sense with which I disagree. In CQRS, you can use synchronization until you have any performance issues.

Also, the commands should be of the void type and have nothing to return with which some people also do not agree “because the command must return the result”. Applies to such methods in the command exceptions, but will write about the exceptions in the next articles.


Summary

In the next article we will go to the code.

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 

– site on fb: Devman.pl-Slawomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want.

 
If that post was useful for you share it with your friends :)

Post a comment

avatar
  Subscribe  
Notify about