introduction

In order to achieve architecture optimization and reduce coupling, the IT industry has put forward many ideas. There are design patterns, architecture patterns, and then interface-oriented and service-oriented; there are use-case-driven design and domain-driven design. However, I personally believe that these are only purely technical solutions to coupling. So I divide the coupling into technical coupling and business coupling . Later, I will combine the two coupling concerns. And experience-driven and abstract-driven understanding.

1 Technology coupling to business coupling

1.1 Overview

Under the Internet open source trend, there are many open source frameworks. For example, redis, dubbo, zookeeper, spring, spring boot, etc. These frameworks are not related to specific industries and specific businesses. In addition to providing the underlying technical support, these frameworks also help us decouple technically and help us divest our business. For example, spring's IOC and AOP.
In addition, many development ideas are also guiding us how to decouple. For example, design patterns, architectural patterns, object-oriented, interface-oriented, service-oriented and so on.

1.2 The problem

These technical frameworks and development ideas give a decoupling method from technology. However, decoupling from business still has many problems to be solved, which is also the most difficult.
For example, the microservice architecture isolates the function provider and the function user, and the function provider and the user exchange information through the service interface. But in terms of business, a service interface with a clear boundary must be defined between the two, whether your service interface is designed reasonably and whether it can adapt to future changes in demand; in addition, how to divide each service and so on. There are still a lot to consider.
If you copy the routine , then the possible result is: your code looks perfectly structured, but once the business is adjusted, the interface may be overturned in a large area. Therefore, whether it is interface-oriented or service-oriented. How to define your interface is very important. Only when the interface is stable can you talk about system architecture stability. Interface stability also involves clear boundaries. Only when the boundaries are clear can functional modules have low coupling and high cohesion.

2 Experience-driven design

2.1 Overview

In order to solve business coupling, the industry has proposed domain-driven design ideas. Roughly, business architects with industry experience extract domain concepts based on their business knowledge, and then isolate functions from the business and design interfaces from the business.
This engineering model has a lot of benefits, mainly as follows:

It is convenient for industry communication, because your code implementation is close to the industry field, so that your maintainers can easily understand the macro functions of the code as long as they have industry experience or understand business documents.
By combining with the business, the module is relatively reasonably divided and the interface is relatively stable.

2.2 The cruelty of reality

Domain-driven design has been highly respected abroad, which has also led to its popularity. Everyone who has seen foreign open source projects must have resonance. There are too many class functions in the code. Hundreds of functions in a class are commonplace, and hundreds or thousands of lines of a function are commonplace.
Compared with machines, the biggest advantage of human beings is the ability of induction, analysis and summarization. However, the amount of information that a person can process at the same time is far inferior to that of a machine. The design principle has a single responsibility . It can be said that it was proposed to circumvent this disadvantage of people.
Therefore, looking at the macro structure of these open source codes, people with development experience can easily and quickly understand. However, once you go into the details, you will be very costly (for example, especially without the aid of documentation, you have to read the details and modify the functions in a self-consistent way). In addition, you will find that as the business is adjusted and refined, you add a small function to it, which will be dispersed into the details of each coupling.

2.3 Causes of cruelty

Development must be combined with business , but business often corresponds to macro and coarse-grained large functions. Especially when the business is refined, it often leads to the expansion of class functions.
Many understandings of domain-driven design place too much emphasis on business experience . What is the experience? It is the accumulation of your past, not to mention the Internet, it is the traditional software industry. Demands are also changing at any time. Just based on experience is often the past and present regardless of the future, then you can only put your business in the code. In this way, future business changes may cause you to restructure on a large scale. It is most likely to be overthrown from the interface.
In addition, if the domain experts do not have deep technical capabilities, the business cannot be designed with technology.
For example, if the signal source is at A and the longest transmission distance is at B, it is necessary to find the point where the signal strength is T (the allowable distance error is D). At this time, the domain expert will give you a theoretical formula t = f(d), d is the distance, and t is the strength. If the domain expert has no computer foundation, it may let you go from near to far with a step size smaller than D. Push closer. However, as an insightful developer, you may find that if d is inversely proportional to t, it can be approximated by half.
The above is just an example of an algorithm. You can think of halving because you understand his formula, or you use conventional thinking (the farther the signal is, the weaker the signal), then ask him for verification, and then combine technical knowledge to get the halving; for domain experts, he knows that the formula is proportional , But he does not understand the half-by-half algorithm.
In fact, experience-driven design is similar. Domain experts only design based on its industry knowledge. Sometimes adjusting the business process will not affect the final result, but it will make a qualitative change in the architecture, provided that you have to understand the business. Of course, even if it is experience-driven design, the people who implement it below must understand the business to better realize the logic. Don't even think that having a domain expert can reduce the cost of business communication for development .

3 Abstract-driven design

3.1 Overview

Although both use case-driven and domain-driven, abstraction is mentioned in it, but they don’t pay much attention to it; at least in many companies, they don’t pay much attention to it, so that they pay too much attention to domain experience and ignore the essence of abstraction. Of course, they can’t taste it. Abstract sweetness.
Abstraction emphasizes normalization and universality, and finally realizes the reduction of business complexity, and then facilitates the development of coding and iterative modification of the later code. Relying on business experience design will lead to code expansion, unable to embrace changes in requirements. Then we analyze and abstract the business and design a more single cohesive functional structure. This can solve the problem of code function expansion, but can we adapt to future changes in demand?
According to development experience, every time the business is expanded or adjusted, it will basically be refactored on the basis of the original code, and the result of this refactoring is to make its original functions thinner and thinner. . That is to say: As long as there is no qualitative change in the field, most business adjustments have many related functional units that can be reused. If we analyze, process, and design business areas more reasonably, we may reuse more functions in the process of business adjustment.
The emphasis here is on the analysis and processing of the business domain, so your processing must be close to the business semantics.

3.2 Examples

It may be more abstract. For example, in the Android source code InputFlinger, you will find that it is complete from the existing business, but there are still many deficiencies in future expansion. For example, the functions at the beginning of notify in InputDispatcher are notified by InputReader. Then after a certain preprocessing, it is distributed in another Dispatcher thread, and each specific event entity in it has related intermediate processing parameters in the form of InputDispatcher member variables.
If we define an abstract processing base class for each specific event entity, provide preDispatch and doDispatch methods, which are separated by each specific event processing class; and our processing of the event queue can also be abstracted as an event queue class , Provide external operations. Then it may be better for InputDispatcher to cohesive or wrap these functions. In this way, the boundary of extending or modifying an event processing becomes clear. In this way, since each class unit has few functions, it also seems very convenient.
In the design process, you have to consider that all your functions are as expanded as possible , only in this way can you design an architecture that embraces the future as much as possible. Even if your product manager tells you that these functions are stable, they will never change in the future. In fact, when he says this to you, it's like a teacher saying to a student: "I will take everyone one minute to finish class!".

3.3 How to refine abstract ability

First of all, we must understand the business and understand the business conceptually. If you don’t understand the business, you can’t analyze the business with technology;
then, if you understand the business, give feedback, just ask for the signal position. As in the example, after many business processes are adjusted, there is no difference for the user, so you can adjust;
secondly, In the design process, you have to believe that the function you are doing may need to be extended.
Finally, to what extent is the analysis complete?
In terms of big principles, see if your design fits the design principles in a modest way; at the same time, the classes you design are finally implemented to the code level. Make sure that each class is as simple as possible, brief and cohesive. Take c++ as an example. In order to realize your design, you must ensure that your class header file can be controlled within 50 lines, whether your function is 30 lines on average, and 99% of the functions are controlled within 50 lines. But then again, if you copy these indicators mechanically, you will return to the model of copying routines, so you still have to focus on the abstract essence to unify the business.

Abstract beauty