Take a look at CQRS and Event Sourcing with DDD — Part 1
As you know Event Sourcing, CQRS (Command Query Responsibility Segregation) and DDD (Domain Driven Design) trend microservices topics. I’ll explain you this topics with a real example. Let’s start, Funkhu!
I want to explain to you these concepts and what they mean. These concepts using for Distributed Systems like microservices or monolith applications but not required.
What is the CQRS?
CQRS allows you to separate the current actions of the application with commands and queries and make them loosely coupled. This may be like separating reading and writing. We can explain the query side as accessing users’ information when you need it. As a single responsibility, you only access the user’s information. We can explain the command side as creating, updating or deleting users. Because the desired thing is no longer the user’s information, but to make changes to the user. With CQRS we can separate these and make the states of the application more regular.
Why we need this while using microservices for our product?
A microservice or monolith application may become complicated after a while. You can see that while updating the user’s information, you also try to access the user’s information. Responsibilities begin to interfere with each other, and maintenance costs can start to become uncontrollable. However, in applications where responsibilities are important, separating responsibilities by using CQRS for a cleaner architecture will be much more advantageous for the future state of the application. For these reasons, we should use CQRS or similar approaches in our projects, whether it be monolith or microservices.
What is the DDD?
To briefly define Domain Driven Design, DDD is an approach that tries to bring solutions to the problems that may occur in the implementation of complex applications and afterwards. DDD is an important approach, but we will not explain its details here. Those who are curious can look here.
What is the Event Sourcing?
How do you ensure that your databases are reliable & atomic?
In an application, transactions happen continuously in the database. But transactions on data may not always happen atomically. On the other hand, an operation related to a table may affect many parties. Here, we can solve these and similar problems with event-based approaches. Event-based approaches can be explained as informing people who want to listen to you when you do something. We call these as domain events. For example, when you create a user, it’s like sending a “welcome email” to this user.
I tried to explain you this concepts as briefly. See you soon with codes and examples on Part 2!
Follow me;
