Original link: https://teddy-chen-tw.blogspot.com/2022/07/8cqrs.html
July 02 06:35~08:20
▲Figure 1: ezKanban applies CQRS architecture diagram
foreword
CQRS is the abbreviation of Command Query Responsibility Segregation , which is translated into ” command and query responsibility separation ” in Chinese. Today we introduce what CQRS is and what problems it can solve.
***
origin
CQRS is a design pattern proposed by Greg Young . Its concept is very simple: design the following two operations separately: operations that change the state of the system but do not return a value, called Command, and operations that do not change the state but return The operation of passing by value is called Query . Greg Young is also an advocate of Event Sourcing. In 2011, he developed EventStoreDB, a database that directly supports Event Sourcing and CQRS. Teddy introduced how to use this database in <Event Sourcing (3): Storing Aggregate in EventStoreDB > Stores realm events.
***
CQRS is sometimes called read- write separation . This concept was not first created by Greg Young. It was first proposed by Bertrand Meyer , the inventor of the Eiffel language and Design By Contract (DBC) , called Command-Query Separation (CQS). The application object of CQS is objects, while CQRS extends the scope to the entire system, including API, Use Case, Domain Model, and Database, which can be read and written separately.
Just check this information on the Internet, and most of the villagers know it, but do you know why Bertrand Meyer proposed CQS?
CQS is related to DBC. When writing a contract, whether it is preconditions or postconditions, it may be necessary to call the method of the object for state verification. Figure 2 shows the deleteLaneById method of Workflow Aggregate in the ezKanban system. ezKanban applies DBC. Lines 117 to 119 are preconditions, and line 131 is postcondition. In lines 119 and 131, the getLaneById() method is called to check whether a lane exists. getLaneById() is the query, which returns a boolean but does not change the object state. Because the contract is written on the object, if the object design does not comply with CQS, then how do you know if calling the getLaneById() method in the contract will accidentally change the system state? Without CQS, DBC can’t play.
It has been more than 30 years since CQS was proposed. Why is it not so popular? Most of the villagers know CQS because of CQRS? The answer is very simple, because the application of CQS is closely related to DBC, and most developers do not have the opportunity to actually apply DBC, so they have not heard of CQS.
▲Figure 2: deleteLaneById method of ezKanban system Workflow
CQRS and DBC are decoupled, catch up with the environment of distributed computing and microservice architecture, and expand their application opportunities, so they are popular.
***
Benefits of CQRS
CQRS has the following three main advantages, referred to as 3S:
- Simplicity : CQRS divides the system into Write Model and Read Model, which have very different behaviors and responsibilities. From the perspective of the Single Responsibility Principle (SRP), CQRS further simplifies the complexity within different models.
- Write to the model:
- Strong consistency
- normalized data model
- one-way dependency
- Read the model:
- Eventually consistency
- de-normalized data model (materialized view)
- any-way dependency
- Write to the model:
- Scalability : The reading frequency of many systems is much higher than that of writing. For example, in an e-commerce system, most users are browsing data, and only a few operations will change the system state. In this case, applying CQRS can be extended for the read part alone, as shown in Figure 3.
- Speed (Performance) : Combining the above two advantages, CQRS can improve the system response speed and performance, because developers can adopt different optimization strategies for the write side and the read side respectively. For example, the writing side adopts Event Sourcing to simplify and speed up the writing operation, and the reading side can use various caching tools to speed up the reading speed because it will not change the state. Figure 4 shows the performance test performed by the ezKanban team after applying CQRS to the real GetBoardContent reading action. It can be found that after applying CQRS, there is a huge improvement in reading performance.
▲Figure 3: CQRS can expand write and read services respectively
▲Figure 4: ezKanban GetBoardContent performance test
***
Are there no downsides?
The above description of CQRS seems to be very good. Does it have any shortcomings? Of course there is.
Although the application of CQRS can simply start from the API layer and the Use Case layer, it is not necessary to separate the read and write of the Domain Model or even the database. However, based on ezKanban’s experience in applying CQRS in the past two years, it finally moved towards the separation of Domain Model and database read and write. The system is “finely” divided into read models and write models at various levels. Although individual models have a single responsibility and become simpler, there are still dependencies between models. How to manage these dependencies becomes a challenge. .
For example, as shown in Figure 1, ezKanban also applies CQRS on the database side, so the state synchronization between the read database and the write database is eventual consistency . In order to maintain eventual consistency, new design work will be generated: synchronous messages need to consider issues such as ordering and at least once, and the Projector (projector) responsible for generating the read database design must consider idempotent Problems with replay events etc. In addition, how to write Projector is also a problem.
In other words, the technical threshold for CQRS to go to the end will be relatively high.
This is why many articles or books recommend against using CQRS for CQRS’s sake, depending on whether your business needs are strong enough to require the benefits of CQRS.
***
Next episode preview
After explaining the basic concepts of CQRS, the next episode will first introduce the effect achieved by ezKanbana after applying CQRS to simplify the domain model, and then introduce how ezKanbana implements Projector and the impact of applying CQRS on the architecture.
***
Youzo’s inner monologue: It’s actually not that difficult after using it.
This article is reproduced from: https://teddy-chen-tw.blogspot.com/2022/07/8cqrs.html
This site is for inclusion only, and the copyright belongs to the original author.