Classic application system structure, cqrs, and event Tracing

Many netizens still do not know much about cqrs and event sourcing, but do not have a rough idea about the differences between the classic application system architecture and cqrs architecture. This article is basically Excerpted from Greg Young's cqrs documents (translated and briefly commented by daxnet), hoping to help fans of application system architecture.

[Note: The content of this article is excerpted and translated from Greg Young's cqrs documents. To view the original text, pleaseClick here]

 

I. Classic Application System Structure

Before learning about the domain driven design (DDD) application system, let's take a look at the classic application system structure. This classic application system structure is often regarded as a standardized solution for designing and developing distributed application systems. It describes this classic application system structure.

The above architecture depends on a back-end data storage system. Although it is usually a relational database, this data storage system can be implemented in many ways, such as using key-value storage, object database, or even XML files. In any case, the data storage system stores the current state of objects in the domain model. The upper layer of the data storage system is the core part of the entire system: Application Server ). An Application Server contains the business logic of the entire system, such as business Verification for external requests. At the same time, "Application Service" is also part of the application server. It provides external interfaces for accessing the domain model and decouples the caller and domain model. The outer layer is remote facade, which can be soap, custom TCP/IP communication, XML documents transmitted through HTTP, tomcat, or input data staff. The role of remote facade is to provide remote proxy and bridge for the interaction between the external system and the application server. The Application Server abstracts and decouples the background data storage system and processes the business logic of the entire system. Such a classic architecture has been very popular, and even now, most systems still use it as the default preferred architecture style.

Now let's analyze the structure of such a classic application system. Such an architecture has many characteristics. Of course, some of these features are very good in some application scenarios, but some of them are not suitable for other application scenarios. As architects, we need to be good at summing up and discovering so that the selected architecture can meet system requirements to the maximum extent possible.

• Simple
  This classic application system structure brings us the greatest feature of simplicity. ElementaryProgramMembers can quickly master the system structure and quickly understand how each part of the system is connected and communicated. "Simple" brings another feature of this architectural style, that is, "General ". It can be used in most projects, so this architectural style has become a general language for discussion about the system architecture: Speaking of layering, it is a classic three-tier (either four or five layers, but it is nothing more than the UI Layer, business layer, and data layer. When talking about the data storage system, it is a relational database, and it immediately associates with tables, fields, constraints, and stored procedures. This "general" feature brings about a benefit: developers can quickly get started with the system. For example, a new developer in a project can get familiar with the system structure and development process in a short time, this saves project expenses to a certain extent.
• Tool-based and framework-based
  Because it is "simple" and "General", it is relatively easy to develop a set of "general" tools/frameworks that support application system development in the classic architecture. There are already many ready-made frameworks that can be used to conveniently and quickly build an application system for this classic architecture. For example, Orm provides ing between domain objects and relational databases. By introducing ORM in the system, developers do not need to maintain this ing, which greatly improves development efficiency, reduces development costs
• Domain-driven
  In this classic application system structure, it is impossible to drive the design by the field, even if many people tried to use this architecture to drive the design by the field (Daxnet: Previously, I also thought that DDD can be used in this architecture. In terms of implementation, nothing is feasible. However, Greg Young does not agree with it because of the general language, of course, Greg Young is not necessarily correct, but he is more practical than us. His inference is more valuable for reference. We also need to understand this difference in practice.). The reason is simply that the object model in this architecture cannot be correctly expressed as a common language. We can easily find that there are only four predicates in this classic architecture: Create, read, update, and delete ), that is what we often call crud. Since remote facade is data-oriented (DTO-oriented), Application Service also needs to provide the same data-oriented interface. This means that the domain model can only support these four predicates. When we communicate with domain experts, we often use a "general language ", the general language is rich in content, not just the four predicates.
• Project Scale
  When we have a deep understanding of this architecture, we will find that when the project scale becomes large, there is a very big bottleneck, that is, the data storage system. Especially relational databases. Of course, although more than 90% of the current systems use relational databases, the expansion of the project scale is not a norm after all. Therefore, the existence of such bottlenecks will not be too big a problem.

In short, the classic application system structure can be applied to the vast majority of system development. It has the biggest advantage of being simple. However, it is not suitable for project development based on the field-driven design. If you have to practice the field-driven architecture, it must fail.

 

Ii. cqrs and event Tracing

Cqrs is complementary to event tracing. Cqrs allows event tracing as a data storage mechanism in the field. However, one of the biggest disadvantages of event tracing is that you cannot ask your system questions like "Please tell me all the users named Greg, this is because event tracing cannot provide the current state of the object. The only query supported by cqrs is: getbyid-obtains an aggregation by ID. The cqrs-based application system structure can be compared with the classic structure.

Comparing the two different system architectures, we found that the workload required by the two in the client is basically the same, the operations performed by clients in two different architectures are roughly the same: Obtain DTO from the system, convert DTO view model, display it on the UI, receive user input, and generate commands, then, notify the application system to perform corresponding operations. In terms of the implementation of the query function, the costs of these two system architectures are also roughly the same: In the classic application system structure, the query is based on the domain model, in the Application System of cqrs structure, query is another thing: it is provided by a simple read access layer (thin read Layer, the read access layer directly maps data to DTO. By discussing the separation of duties between commands and queries, a simple read access layer will not cost much. On the contrary, it will save costs in many cases.

From the perspective of cost, the biggest difference between the two system architectures should be the domain model and its persistence. In the classic architecture style, in order to make the domain model persistent to the database, the ORM usually undertakes a lot of work, however, this also produces an "impedance imbalance" between the domain model and the persistence mechanism. This effect eventually leads to a high cost expenditure in the production environment. At the same time, developers also need more knowledge and experience to address problems caused by impedance imbalance. In the cqrs architecture style, from the perspective of Part C (command part), there will be no such "impedance imbalance" effect. Domain Models generate events, while data storage systems store these events. Domain Models only focus on these events. However, in the Q part (query part), an "impedance imbalance" occurs: The Event processor (Event Handlers) needs to update the query database based on the specific event data, the impedance imbalance occurs between the event and the Data Relationship Model. However, the impedance imbalance effect of the query part is much less than the impedance imbalance effect between the domain model and the relational database, and the impedance imbalance effect of the query part is easier to process and solve. This is because the event itself has no structure, and it only expresses the measures to be taken for the relational model.

From the above considerations, the workload of these two different types of system architecture is almost the same, there is no additional workload, and there is no less workload. This is two completely different jobs. During modeling, the application system based on the cqrs architecture seems to have some extra work to do, because you need to define a series of event objects and write the event processor; however, this workload is relatively small, which effectively reduces or even avoids the "impedance imbalance" effect. In fact, in most cases, application systems based on cqrs and event tracing are more cost-effective and efficient.

 

Iii. Summary

do not stick to it because cqrs looks more advanced. This can only give you lessons of failure. The architecture and Technology Selection of the entire system should be accurately determined based on the actual situation of the project, which is also the main responsibility of the architect. Although most of my blogs are discussing domain-driven design and cqrs, this does not mean that I will resist the classic architecture style, I also constantly learn and think about the classic application system structure. I just hope that I can organize some new things through blog, it also helps software design and architecture enthusiasts to broaden their horizons and enrich their knowledge.