The introduction

Some time ago, I just finished reading Pattern-based Software Architecture: Volume 1. At the same time, I also participated in the preliminary technical discussion and Framework development of EBF (Extensible Business Framework, known as “Wind in my ears”). Therefore, on the one hand, I take this opportunity to summarize my feelings after reading, and on the other hand, I will do a brief knowledge precipitation based on the problems ENCOUNTERED in work. In view of the length of my reading notes and the complexity of the problems in my work, in order to better focus on the problems and make it easier for everyone to read, this blog will concentrate the relevant knowledge points based on specific scenes and stories.

As a programmer of business coding, I think the improvement of business coding ability will not be limited to the glue code of CRUD. More likely to apply the GoF design pattern (gang of Four, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, 1995) to scenariospecific code design problems, There are also applications of DDD (Domain-Driven Design by Eric Evans, 2003) domain-cohesive patterns to address the issue of sustainable delivery.

Of course, we’ve had these problems before: where do we start to split a single service? As systems become more complex and difficult to iterate, how do we make them scalable?

Introduction to the

“Pattern-oriented Software Architecture” consists of five volumes, of which the first volume mainly explains the collaboration between patterns and software system architecture. The author believes that patterns are replicable solutions derived from experience in specific scenarios, which can be applied in scenarios. Of course, the implementation of the solution creates new problems/scenarios to be solved by other patterns. The book also contrasts and combines architectural patterns with GoF design patterns.

(Source: electronic version)

Architecture patterns can be used at the beginning of coarse-grained design when specifying the basic structure of an application. When detailing a design, a design pattern specifies the approach to the detailed design phase. The book also condenses and summarizes GoF design patterns. The book does not give a detailed overview of the various patterns and related variations, as well as the use of combined systems. On the whole, the content of the book is more pragmatic, from scene enumeration, problem listing, solution to the application of pattern analysis and variant mode, are very detailed, but the translation quality deviation, many sentences read more obscure. Second, the book was published in 2003 (when DDD was published), and the technical terminology and concepts are slightly different from those of modern people.

This time, we will analyze and discuss the two topics of “single application splitting” and “complex system improving scalability” by architecture mode, and solve how to complete the initial stage of coarse-grained design through pattern programming before application architecture design.

​

Monomer application split

The term “monolithic applications” may seem archaic, as many companies today have technology structures that work together as multiple services, with very few monolithic entities. But, as a business development needs to face up to the point that is itself a steady stream of demand, and its complexity itself is immutable, it is hard to through a model to solve the complexity of the demand itself, but rather through the mode that the programming language is more clearly, more friendly, more extensible expressed needs logic, this information is a kind of escape process), Therefore, in the process of continuous requirements iteration, lightweight “monomers” will gradually become heavier (sometimes due to inverted requirements, the code quality is sacrificed to complete the task under limited effort, increasing the burden of the overall structure).

When the “monomer” reaches a level that requires more people to absorb new requirements and system maintenance, the “monomer” assistance problem arises. At this time, it is extremely important for its code boundary and programming specification. At this time, the communication cost and responsibility boundary are very high. I once came into contact with a “single” maintained by more than 10 people, because the code is all together, and when there is no boundary distinction in the early stage, everyone has his own design principles. When the boundary is separated and the rules are set, we start to worry about the learning cost and error cost of new recruits. Therefore, at this time, we consider the separation of “individual” and reduce the influence of human factors through physical isolation.

​

The above is a corrupt set of monolithic applications, coded through transaction scripts, the layers of which are relatively well defined and will not be covered here. To illustrate the main problem shown in the figure above, the Servcie layer of Module A is used as the service layer to deal with the specific business logic of Module A. At this time, relevant business capabilities of Module B and C may be called. In A “single” without explicit contract management, It is very likely that the Service of A calls the Dao of C, which is undesirable and will gradually corrupt the whole project, even to the Controller layer.

  • Module C has no control over which capabilities are invoked, making the impact surface of the new requirements iteration impossible to assess.
  • For Module A, the Service layer is chaotic. As A single application, no matter where the Module Dao is, it does not have A great impact on it. However, with the increase of coupling complexity, the business logic of Service may be affected when it is separated into RPC in the future.
  • It is also possible that the Sql joins tables from different Module DAOs, thus completely coupling.
  • This also causes the boundary of Module is not clear, and it is difficult to identify where I should write when developing new requirements.

For many people, this event may be managed by self-restraint, but it is a kind of artificial restraint after all, and there will be communication and management costs, and the costs are very large.

The solution

First, according to the scenario, it is a problem from chaos to structure. Layers, pipes and filters, and blackboards are all good choices for this particular scenario. Often our first instinct is to layer things up. Layer is a kind of non-reverse top-down transmission of structural ideas, and each layer is independent, the work of the layer can be closed loop. The “Controller”, “Service”, and “Dao” we talk about a lot are basic hierarchies.

  • Controller is responsible for input/output and service applications.
  • The Service is responsible for business logic assembly, and there may be a Manage layer for Dao assembly.
  • The Dao is responsible for database operations.

Regardless of the merits of the domain model versus transaction scripting approach, the current situation is that we need to solve the problem of layer coordination and layer capability closed-loop.

As shown in the figure, the System Layer is a very familiar “Controller Service Dao” model, which is relatively pure and needs to be standardized for each Layer

Input/output objects, and paths are vertical from top to bottom. The Business Layer is often the key, which is also the point we need to think about when we split each Module, such as which Module is a Module and how to assist among multiple modules. There are a few rules of thumb:

  • Modules should have as few dependencies as possible on each other, and the rough measure is to have as few interfaces as possible with each other.
  • The separation of the primary consideration can be thought along the business process, which is more intuitive and easy to communicate, and the process sequence should be as far as possible without reverse dependence, to reduce the problem of repeated coupling between modules.
  • During the separation period, physical separation can not be carried out at first, and it is very important to prioritize the isolation and specification of code modules.

(Photo: a corner of the whiteboard taken in 2020 while stratifying through the domain event Storm)

Of course the actual business layering is thought of in terms of business-specific attributes and is more vertical. But in general, try to reduce coupling as much as possible and make the layers more cohesive. After splitting, we need to pay attention to how the layer closes the loop and accepts the upstream business for relevant logic processing. Here, we need to introduce the concept of business identity. Because each layer is self-closed loop, exposing the interface, it is necessary to identify the processing logic related to upstream business through business identity identification.

(Business identity has a rich identity-configuration relationship logic in the corporate platform, which is not discussed here.)

  • Both business A and business B, respectively, flow into business C, which needs to determine the business logic executed by the identity they pass.
  • The defined business identity is very important and needs to be enumerable based on business status rather than any state, type being an identity. For example, when placing an order, it will identify what logic needs to be processed in the current scenario according to the business identity of the order (political purchase/individual purchase/enterprise purchase, bidding/group purchase, etc.).

In short, we divide the boundary by stratification, turning chaos into structure. Each layer needs to consider its cohesiveness and self-closed loop, connecting upstream and downstream logic through business identity.

Complex systems improve scalability

As a system becomes richer and more complex, we want to extend the complex logic to enhance the adaptability of the system as a whole. There are also many common GoF design patterns: adapters, decorators, policies, and so on. From the perspective of coarse-grained system design, Pattern-Oriented Software Architecture describes the microcore architecture pattern to provide system adaptability. This pattern separates the minimum functional core from extended functions and customer-specific parts, and coordinates plug-ins to provide a “plug and play” software environment.

The book describes the solution of the new operating system, after all, the concept of microkernel comes from the operating system, but we want to apply this mode to the business system, we need to change the thinking mode.

The picture above shows a micronucleus structure as outlined in the book, but the actual content is much richer. Among them, system adaptability is mainly reflected in the up-down linkage of programming interfaces. There is also a layer of adapters on the programming interface side, which is not shown in this example to address the adaptation of different operating system applications running on the same operating system.

  • Microkernels provide minimal and core capabilities and coordinate application execution. All extensibility is achieved through applications, and microkernels provide mechanisms only, not policies (that is, abstractions only).
  • External servers are domain-specific guidelines from which the functionality required by the application domain can be determined. External servers converge on each approach and provide services using microcore interfaces that allow clients to program applications. (External server is the name given in the book, probably because the client is treated as an external system and used as a Facade.)
  • The client implements specific functions, known as “applications,” through the programming interface of the external server.

In combination with the business system, when our complexity reaches a certain level and the business scenarios have a certain amount of exhaust, we can analyze whether the business domain is suitable for the structure mode of microkernel. The interior of the microkernel can be composed of abstract models and standard definitions, and the external server can be the embodiment of business capability points, which is also the general idea of EBF framework. Of course, the interior design will be very rich, and the microkernel is only a structural mode to solve the adaptability, and other problems generated by it need to be solved by other modes.

Among them, the business capability point is the key to the design of the whole micro-core pattern. When we analyze the expansion of capability point, for example, an order has the ability to create an order, and at the same time, the action of this capability will send a message to the supplier after the order is created. Because the logic of this part of the message is different for each business scenario, we consider it from the domain design model: sending messages should not be the ability to create orders, but should be done by the message support domain, which simply invokes the sending ability of the message support domain.

Through the microkernel mode, the business standards are sunk into the kernel, and the operational capabilities that are not directly related to the application domain but are needed to realize the system infrastructure are established, which can enhance the overall applicability of the system. At present, EBF framework is still in the design, and has a small stage of results, we are also committed to the business architecture thinking to solve complex enterprise system, make business delivery programming implementation easier. Looking forward to those who are looking for direction in business coding, join the political cloud technology team.

conclusion

The design of architecture mode is based on the solution provided by a specific scene, which can be divided into “chaos to structure”, “distributed system”, “interactive system” and “adaptive system” from the characteristics of the scene problems. When solving the problem of single application splitting or extensible system, the boundary can be divided by layers to realize the cohesion of modules. Microkernel patterns can also be used to analyze the functionality of the application domain, to set standards, and to establish the operational capabilities necessary for the infrastructure.

There are many details missing in the content of the above article (the details of the micro-core part are not described due to the length problem), which can be supplemented in subsequent articles. If there is any deviation in personal understanding, we can also discuss and learn together with comments and messages.

Recommended reading

Exploration of low-cost screen adaptation solution for Zhengcai Cloud Flutter

Redis Bitmaps

MySQL InnoDB lock system source code analysis

, recruiting

Zhengcaiyun Technology team (Zero) is a passionate, creative and executive team based in picturesque Hangzhou. The team has more than 300 r&d partners, including “old” soldiers from Alibaba, Huawei and NetEase, as well as newcomers from Zhejiang University, University of Science and Technology of China, Hangzhou Electric And other universities. Team in the day-to-day business development, but also in cloud native, chain blocks, artificial intelligence, low code platform system, middleware, data, material, engineering platform, the performance experience, visualization technology areas such as exploration and practice, to promote and fell to the ground a series of internal technical products, continue to explore new frontiers of technology. In addition, the team is involved in community building, Currently, There are Google Flutter, SciKit-Learn, Apache Dubbo, Apache Rocketmq, Apache Pulsar, CNCF Dapr, Apache DolphinScheduler, and Alibaba Seata and many other contributors to the excellent open source community. If you want to change something that’s been bothering you, want to start bothering you. If you want to change, you’ve been told you need more ideas, but you don’t have a solution. If you want change, you have the power to make it happen, but you don’t need it. If you want to change what you want to accomplish, you need a team to support you, but you don’t have the position to lead people. If you want to change the original savvy is good, but there is always a layer of fuzzy window…… If you believe in the power of believing, believing that ordinary people can achieve extraordinary things, believing that you can meet a better version of yourself. If you want to be a part of the process of growing a technology team with deep business understanding, sound technology systems, technology value creation, and impact spillover as your business takes off, I think we should talk. Any time, waiting for you to write something and send it to [email protected]

Wechat official account

The article is published synchronously, the public number of political cloud technology team, welcome to pay attention to