CQRS and Event Sourcing as an antidote for problems with retrieving application states - nexocode (original) (raw)

CQRS and Event Sourcing as an antidote for problems with retrieving application states

Nowadays, every developer is familiar with the standard architectural pattern MVC. Most of the applications are created around this approach. It allows us for creating big enterprise apps which are scalable and extensible, but recently we can hear more and more about CQRS/ES. Should these approaches be used together? What kind of problems can be fixed by them? Let’s have a look at what these patterns are and what are pros and cons of using them.

CQRS - pattern overview

CQRS (Command Query Responsibility Segregation) is a very simple pattern. It comes from CQS which stands for Command Query Separation and it was devised by Bertrand Meyer. According to this, methods in the system should be separated into two groups: commands that mutate the state and queries that return a value. Applying this idea to objects or components introduces a new concept - CQRS introduced by Greg Young. The main idea behind it is that classes or components within the application changing state (commands) should be separated from the components which getting the state of the application (queries).

Structure of CQRS part of our application can be illustrated by the following schema:

CQRS Pattern

Commands represent user intent. They contain all the necessary information about actions that user would like to perform.

Queries are objects, which represent the actual state of application available for a user. Getting data for UI should be done through these objects.

We can distinguish many advantages of CQRS approach including the following:

Despite all the above benefits of using the CQRS pattern, we should be very careful using it. For a low complexity projects, with simple domain, where UI model corresponds closely to domain, CQRS would be a great example of over engineering and redundant complexity. Moreover, the implementation of CQRS for projects with low number or requests won’t bring significant performance increase.

Event Sourcing - case study

At nexocode, we were trying to solve a problem of storing the previous states of the domain objects that influenced current state. Particularly, we were interested in generating statistics at any point of time. We wanted to check the state of our aggregate from the last month, last quarter or any other date from the past. The problem was not easy. We could keep additional data in the database for particular ranges of time, but there were also some drawbacks to this approach. We didn’t know how ranges should look like and what data would be necessary for future statistics. To avoid those problems, we could make snapshots all aggregates every day, but it produces a lot of redundant data.

Event Sourcing seems to be the best solution for that problems. Event sourcing allows us to keep every change of aggregate state as events in a repository called Event Store. Publishing event by command handler should finish with saving event in write DB (event store) and initiating logic handled by event handlers. To create the current state of aggregate we need to run all events which create expected domain object and perform all changes to it. Below schema should explain that idea in a clear way:

Event Sourcing

We are able to specify some advantages of ES:

Aggregates

I used word aggregate many times in this article, but what does it mean? It is a concept that comes from Domain-Driven-Design (DDD) and it refers to the entity or group of related entities which are always kept in a consistent state. We can think of it as a box which accepts and handle commands (contains command handlers) and then generates events based on the current state (applying events on event bus). In our particular case aggregate root is composed of one domain object, but it can be composed of multiple objects. We have also to be aware that the whole application can consist of multiple aggregates and all events are stored up in one repository.

Conclusion

CQRS/ES can be a good alternative as a solution for specific problems. It can be introduced in some parts of the standard n-layer app and it can resolve non-standard problems where not only the current state is important, but also in places where we have to know how current state was built. Are CQRS and ES concepts that should exist together? In fact, no. Write DB can store only the current state. It wasn’t the case in our application and introducing CQRS only didn’t resolve our problem. We’ve implemented CQRS/ES using Axon framework for resolving some specific problems of one of the domain objects, especially gathering statistics. The next step is to prepare for recreating aggregate in time. In the near future, I’ll describe how CQRS/ES can be implemented with Axon framework and easily integrated with Spring Boot application.

You can find more details within following articles:

About the author

Łukasz Kucik

Łukasz Kucik

Software Engineer

Łukasz is a Software Engineer with industry experience building large-scale web applications. He provides full-stack solutions but mainly focuses on BE with Java, Kotlin, and Spring.
He believes that working in small Agile teams is the key to significant results, as good communication guarantees success. Łukasz's daily routine includes improving his coding skills by introducing clean code standards and refactoring.