Introduction to CQRS and Event Sourcing

Table of contents

Reading Time: 3 minutes

CQRS

CQRS (Command Query REsponsibility Segregation) is a very simple pattern and not new at all. CQRS is based on the Command Query Separation (CQS) principle which was suggested by Bertrand Meyer. CQS suggest that we divide the operation on domain object into two distinct categories: Queries and Commands.

The Command and Query Responsibility Segregation(CQRS) it’s an architectural Pattern Where the main focus is to separate the way of reading and writing the data. This pattern uses two separate models.

Queries – Which are responsible for reading data.

Commands- Which are responsible for updating data.

Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and Prevents update commands from causing merge conflict at the domain level.

Commands

Commands represent the intention of changing the state of an entity. They execute operations like Insert, Update, Delete. Commands objects alter state and do not return data.

Commands represent a business operation and are always in the imperative tense because they are always telling the application server to do something. A command is an object with a name of an operation and the data required to perform the operation. For example:

public class DeactivateProductCommand : ICommand
{
    public readonly int InventoryItemId
    public redonly string Comment;
    public DeactivateProductCommand(int id, string comment)
    {
        IventoryItemId = id;
        Comment = comment;
    }
}

The commands are interpreted by the CommandHandlers and they return an event, which can be a successful event or a failure event. If the command succeeds it will create a successful event, and if the command fails it will create a failure event.

Queries

Queries are used to get data from the database. Queries objects only return data and do not make any changes.

Queries will only contain the method for getting data. They are used to read data in the database to return the DTOs to the client, Which will be displayed in the user interface.

Queries will only contain the methods for getting data. They are used to read the data in the database to return the DTOs to the client, which will be displayed in the user interface.

Queries usually start with the word Get, because queries ask for the application to provide some data, for example:

public class GetProductByIdQuery() : IQuery
{
    public int Id { get; set; }
    public GetProductByIdQuery(int id)
    {
        Id = id;
    }
}

When the CQRS should not be used?

In the case of simple user interface e.g. CRUD style and data access operation is sufficient.
When you have simple business logic, the implementation of CQRS would be too overwhelming.

When to use CQRS

Consider CQRS for the following scenario

Has a high demand for data consumption
The system is expected to evolve over time and might contain multiple versions of the model, or where business rules change regularly.
There is the need for one team focus on the complex domain model that is part of the write model, while another team can focus on the read model and the user interfaces.

Conclusion

The CQRS Pattern can be very handy for more complex applications or applications where we have a high demand for data consumption. For more command scenarios where just basic operations will be executed, the CQRS can create unnecessary complexity to the application. So before deciding if you will implement CQRS or not, you always should consider what your application demands.