Shulou(Shulou.com)06/02 Report--

This article focuses on "how to write concise CQRS code", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor learn "how to write concise CQRS code".

The separation of command and query responsibility (CQRS) is a mode that separates the read and update operations of the data store. Implementing CQRS is said to improve performance, scalability, and security. The flexibility created by migrating to the CQRS model enables the system to evolve better over time. However, the CQRS pattern has some well-known pitfalls, and this article introduces three practical scenarios.

The CQRS pattern works wonders: it maximizes scalability, performance, security, and even breaks the CAP theorem (1). Nonetheless, CQRS got a controversial name because of the complexity of its introduction. For example, Martin Fowler argued in his CQRS article (2) that the pattern should be applied sparingly or even cautiously.

For most systems, CQRS increases the complexity of risk

You should use CQRS very carefully.

Although CQRS is a mode in the toolbox, it is important to note that it is difficult to use well, and if not handled properly, it is easy to break your important parts.

From my point of view, the complexity of CQRS is largely accidental and avoidable. To illustrate my point, I'd like to first discuss the goals of CQRS, and then analyze the three sources of complexity common in CQRS-based systems.

The goal of CQRS

The goal of CQRS is to use multiple models to represent the same data, regardless of scalability, availability, security, or performance. Representing the same data in multiple models is the goal, and the rest are by-products. You don't believe me? Listen to Greg Young's speech at the DDDEU2016 conference (3), he said that CQRS was invented to support Event Sourcing (event traceability) implementation. And as you probably know, the Event Sourcing model is powerful for writing data, but bad for reading data, which is why he needed CQRS: multiple models to represent the same data.

How does CQRS achieve this goal? By ensuring that there is only one model as the source of the data, all changes are made through this model.

Let's take a look at how this interpretation can help us solve some complex problems.

Complexity trap 1: one-way command, or excessive isolation

As far as I know, all definitions of CQRS follow this pattern.

CQRS is based on the CQS principle, which states that operations should be divided into two groups: commands that change data and commands that query data. Once we elevate this principle to the architectural level, we get a system where use cases are isolated into the same two groups: commands and queries. Each use case can be either a command or a query, but it must not be both a command and a query.

Once the use cases are isolated, we get a lot of benefits: multiple models, different persistence mechanisms, independent extensibility, and so on.

Do you feel that there is a problem here? The problem is subtle: all CQRS definitions usually start with solution-isolation and then define problem-multiple models. This leads to too much enthusiasm for isolation: commands are even defined as one-way, the operation server only returns Ack/Nack responses, and some actual commands stored in the read model must be polled to return results. In other words, complexity is like a hell of a release.

Solution: relax quarantine

Let's take a step back and reconsider the issue of quarantine. We have seen that, according to CQRS, in order to represent the same data in multiple models, a use case can both write and read data. It goes without saying that reading the model should not update anything, otherwise we will end up with multiple data sources. But should you really let your orders idle?

In fact, without violating any principle, a command can safely return the following data.

Execution result: success / failure.

If failed: error message or validation error.

If successful: the new version number of the aggregation.

This information will greatly improve the user experience of your system because:

You don't need to inquire about the execution result of the command from an external source, you can get it right away. It becomes very simple to validate commands and return error messages; and

If you want to refresh the displayed data, you can use the new version of the aggregation to determine whether the view model reflects the executed commands. No more stale data will be displayed.

Speaking of data, can we relax the isolation a little bit? In many cases, any data contained within the affected aggregation can be returned as part of the command execution result. However, there is a slight difference here: make sure that the returned data can be queried later from one of the read models. Otherwise, there may be a potential risk of data loss if the response does not reach the client.

You can see an example of this in Daniel Whittaker's blog (4), where he discusses the use of command execution objects to verify commands.

In addition, in this gist (5), you can see the command execution result object I used in C #.

Complexity Trap 2: Event sourcing (event traceability)

Due to historical reasons, CQRS is closely related to the Event Sourcing model. After all, CQRS was invented to make the Event Sourcing model possible. However, let's re-evaluate the coupling between the two modes.

As I said before, the goal of CQRS is to allow the same data to be represented in different models. If you are using the event source domain model, you definitely need CQRS to execute the query. However, there are many other reasonable reasons to implement CQRS, which have nothing to do with event source.

Your system displays its entities in different representation models.

You must support different query models (search, graph, document, etc.).

There is a big difference between writing and reading, and you want to extend them independently.

You don't like ORM.

Does this mean that in all these cases, you have to take the Event Sourcing route? If you do this, you will be caught in a complexity trap. Event source is a way to model a business domain, and probably the most complex one. Therefore, you should adopt Event Sourcing only if your business area justifies your business area. Let's take a look at how to implement CQRS in other cases.

Solution: CQRS! = Event Sourcing

We have learned to generate projections by writing event handlers. If there is no event, how to implement the projection? There is another way to achieve projection, which I call "state-based projection". This topic is worth writing a separate post, but I will briefly introduce three ways to implement state-based projection.

1. "dirty" sign

You can mark an updated entity by setting the IsDirty flag and implement a projection engine to query dirty instances and project the updated data to different models. To reconstruct the projection, all you need to do is set the dirty flag for all records.

two。 Additional

In a relational database, you can track submissions on the surface. For example, in SQL Server, you have a built-in mechanism, the "rowversion" column. This function can also be implemented in other relational databases. The projection engine will query the updated rows in a manner similar to replenishment and project the updated data. To reconstruct a projection from scratch, you must "roll back" the last known commit id to 0.

3. Database view

If you are using a relational database and all you need is a different model to represent its data, then the database view is easy to use. Yes, a fully effective CQRS system can be implemented in a database. This may be the least sexy solution-but it not only works, but also naturally follows the CQRS pattern.

The methods of these projection models may not be cool or sexy, but they are effective. I've seen a lot of projects that use these methods, and they work well without being overwhelmed by the complexities associated with event source for no reason.

Wait, did I just suggest ignoring Event Sourcing at all costs because it's complicated? Of course not! Event Sourcing is one of the most important tools in your toolbox. But, as any tool, use it in its context-an area of business that brings business value. The core subdomain. On the other hand, generic subdomains and support subdomains, which are simple enough to be implemented in transaction scripting or activity logging mode, can still benefit from CQRS. In this case, use the simplest tools to get the job done, and use state-based predictions to reap the benefits of CQRS.

Complexity trap 3: there are too many good things

The hype of microservices has attracted a lot of attention to CQRS: if you have a separate set of services that need to query each other's data, then CQRS is the general solution (6). However, I have seen that this approach produces a huge data flow graph, projecting large amounts of data between services.

This is not necessarily a bad thing, but in many cases it may be a sign that you need to take a step back and rethink your decomposition strategy. It is possible that your service is too detailed to reflect the boundaries of the business area. If this is the case, you can greatly reduce the complexity of the architecture by realigning the service boundaries with the corresponding business domain.

CQRS: deconstruction

I'd like to summarize it with CQRS's diagram.

This chart is different from other charts you can find online.

This is what I see and implement the CQRS pattern. The command is responding. The defined projection mechanism is abstract and independent of the implementation details. It may be event-based, or state-based, or even database views. Finally, there is no event source (Event Sourcing). According to the requirements of the business domain, the business logic of the system is modeled: activity record, domain model or event source domain model.

Like every tool that is applied correctly, CQRS should reduce complexity, not induce it. If the complexity of your architecture increases, you may have made a mistake.

At this point, I believe you have a deeper understanding of "how to write concise CQRS code". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.