Abstract
In the previous article ddD-CQRS can solve the problem, described what is CQRS. But there is no business requirement to apply CQRS. Recently, a business needs to deal with a text incremental update. After requirements analysis, WE tried to use CQRS to solve this problem
Problem analysis
A text page edit, the object is large, before the full save. The network transfer object involved is relatively large and often times out of OOM, so the interaction is changed to save only the modified part, that is, incremental update.
CQRS could not be used in the business before, because the maintenance of data became extremely troublesome after using CQRS. For example, I have repeatedly modified a form and generated N copies of historical modified data. When obtaining the latest data, I need to merge these historical data, which becomes extremely troublesome. This business can be used because,
- Split write to reduce data transmission.
- Read and write can be separated and expanded separately
- Through event traceability, data can be restored to any edited version
The specific design
The whole system adopts CQRS+Event-Sourcing
CQRS
The CQRS pattern separates the operations of reading and updating data by using different interfaces. CQRS mode maximizes performance, scalability, and security, and also provides more flexibility for continuous system evolution, preventing Update commands from colliding at domain model Level.
The domain model of text editing is very thin with no domain verification and constraints. It is separated by reading data/updating data. When the reading and writing pressure is different, it can be divided into different services and expanded separately.
Event Sourcing
B. Obtain the latest status of the object through Event Sourcing (ES);
The whole system is divided into three parts
A command.
All data modification commands, update commands, revoke commands, and overwrite commands are stored persistently in CommitRepository. An event message is then emitted
2. The event – the handle
In the case of text editing, the event handling is basically merging the submitted Command events. Otherwise, too many data update events need to be processed and the event tracing takes too long.
Three query.
Query data, can obtain any commit data according to the modified record.
The three parts are separated and can be deployed as a single service or decoupled to multiple services for easy expansion.
Problems that need to be solved
- How to ensure the order of events
A typical problem with CQRS is that the sequence of events on the production side is inconsistent with the sequence of events on the consumption side, resulting in inconsistent data. How to solve it?
The Command processing section processes all data update sections, generating a globally ordered commitiD that represents the order of updates. That’s the order of events on the production side, but not necessarily the order that gets to our consumption side. So the consumer side, after the event processing is completed, will update the latest commitiD consumption. If the commitiD of the current event is smaller than the latest CommitiD, the event is abandoned.
-
How can I ensure read Data Performance? The Event Handle part is used to merge commit data. Therefore, read data is not merged from all modified data Commit data. The data has been preprocessed so that reads are faster and can be controlled to within 5 to 10commits.
-
Will the data be lost
After system separation, there is no transaction guarantee, how to ensure the integrity of data.
If the data update Command is successfully written, the data is successfully updated and will not be lost. Since the data has already been persisted, all that remains is to read the Command Commit. We can merge these commits to get the latest complete data. So even if part of the Event-Handle goes down, the latest data can still be read.
instructions
In this case, there is still no application framework. I have investigated Axon and evaluated that it is not suitable for use at present. The code is not readable and the benefits are not obvious. Consider whether you need to introduce a framework later.
DDD series
How our team landed DDD (1)
Landable DDD (2)- Why is the MVC engineering architecture obsolete
Landable DDD(3)- How to use DDD to divide microservices
Landable DDD(4)- How to Use DDD to partition microservices (2)
Landable DDD(5)- Tactical design
How to avoid writing bad business code (1) – Domain objects and domain services
How to avoid writing bad business code (2) DDD rectification
What problems can DDD-CQRS solve
A heated discussion about convergent roots