Thinking on the Rationality of System Architecture | JD Cloud Technical Team

Recently, I took the lead in sorting out the rationality of the system architecture of the department. Before starting work, the first thing I thought of was how to define the rationality of the architecture?

From the perspective of research and development, if the system context is clear, the application architecture design is simple, and the application split is reasonable, it should be called a reasonable architecture.

Based on the above definition, the evaluation can be sorted out from the following three aspects:

1. The context of the system is clear: clearly know the call relationship with the surrounding system, and the data synchronization mechanism;

2. The design of the application architecture is simple: the architecture is layered reasonably, the function positioning is clear, and there will be no things outside the functional boundary;

3. Reasonable splitting of applications: the granularity of applications in the system is within a reasonable range; the call link between applications should not be too long.

The context of the system is clear

The term system context diagram was first borrowed from Simon Brown's C4 model, which "abstractly expresses the meaning of architecture by redefining boxes and dashed lines at different levels of abstraction".

The C4 model divides the system into four layers, and each layer represents a different view architecture with different concerns. The first layer, the system context, is the high-level abstraction of the system.

The figure below shows the interaction between different systems in the process of browsing accounts of personal bank accounts. If Internet Banking System is regarded as our target system, then E-mail System and MarinFrame Banking System are its accompanying systems, which can also be called external systems, which provide system value to Internet Banking System, which are outside the system and are black boxes.

The system context defines the relationship between the target system and the external system, and together with the external system, it provides value to the target user. When drawing the system context, you need to pay attention to the direction of dependencies between the target system and external systems. Northbound dependency means that the external system calls the service of the target system, and it is necessary to consider what kind of service contract the target system defines; southbound dependency means that the target system calls the service of the external system, and it is necessary to understand the interface, calling method, and communication of the external system Mechanisms, and even what the target system should do when the external system fails.

In addition to referring to the above drawing method, it can also be represented by a business sequence diagram. It was born out of UML's sequence diagram. Sequence diagrams can start with the roles on the left, showing the order in which messages are passed. This implies this kind of driving force: we start from the participating objects on the left, look for the execution steps to cooperate with them, and then deduce the entire complete collaboration process layer by layer.

The enterprise sequence diagram represents the abstraction of the enterprise-level system, the collaborative relationship between the target system and the external system, and the participating system is a complete whole, so it does not need and should not participate in the details of the internal implementation of the system, and the direction of the message is more important. Many represent the responsibility of the system. The business sequence diagram looks like this:

Simple application architecture design

The application itself has a layered architecture. Martin Fowler proposed in "Enterprise Application Architecture Patterns" that a reasonable system layer should include the presentation layer, domain logic layer, and data source layer. The presentation layer mainly provides services and handles user requests. The domain layer is the processing logic and is the core of the system. The data source layer communicates with the data layer, message system, and other software packages.

The subsequent development of the domain-driven architecture design has evolved into four layers, adding the application layer under the presentation layer, and changing the data source layer to the infrastructure layer, breaking through the limitations of the database management system.

Based on the above system layering, whether you adopt a three-tier architecture or a four-tier architecture, the application represents the functional boundary, providing those core capabilities, what can be done, and what can't be done.

A good practical experience is to refer to the methodology of the business domain of domain-driven design, sort out the first, second and third-level domains of the system, and not exceed four levels at most, and define the domains at all levels. A good domain definition represents the boundaries of system capabilities, allowing you to understand what can and cannot be done.

Based on the definition and capability boundaries of the system business domain sorted out above, we usually sort out two types of systems. The first type is an existing system with relatively frequent iterations of requirements. The key to this type of system is to sort out What are the core capabilities, whether they are within the domain definition of the above system, whether other systems have similar capabilities, and if so, need to consider merging. In addition, it is also necessary to consider the openness and documentation of core capabilities, at least let the department know, and have a place to check, so as to avoid the repeated creation of the wheel of the system.

The second type of system is a stock system and there is no demand iteration, and there is basically no call volume in business. This type of system needs to communicate with the business whether there is an offline plan, whether there is a similar system that can be replaced, and provide technical reference for business decision-making.

Reasonable app split

In requirements development, the realization of a project or requirement may require the collaboration of multiple target systems, which involves the granularity of target system splitting. There is no uniform standard for the granularity of splitting a system into applications, but it must be within a relatively reasonable range. Factors that can be considered include business planning, system call magnitude, architecture design based on business planning, number of people in the department and division of labor. Too much or too little is bad.

If a new business does not see major development in the short term, it can be split in a coarse-grained manner when initially planning the application. The average number of people in the department should not exceed 2-3 applications. If there are more applications, there will inevitably be a time when a demand is realized. Switching costs between different systems. If the follow-up business develops and the number of people in the department increases, because the division of labor is finer, more fine-grained splitting can be considered. The splitting of the system will inevitably bring about another problem, how to coordinate between systems and how to link the system calls length.

Based on the concept of system layering mentioned above, the systems in the department can be divided into two types, one type is the business gateway, and the other is the general business capability. The business gateway is user-oriented and used to coordinate application activities. It does not contain business logic and does not retain the state of business objects. It is equivalent to domain-driven design application layer + presentation layer. Some people call it business SOA or BFF layer.

The general business capability is equivalent to the domain logic layer + infrastructure layer. As the core of the software, it retains the state of the business object, and the persistence of the business object is entrusted to the infrastructure layer. The infrastructure layer serves as the support layer for other layers to realize In order to communicate with other systems, it realizes the persistence of business objects.

In the above two types of systems, the service gateway is dependent on the general service capability layer, the service gateway is northbound dependent, and the general service capability layer is southbound dependent. It is not recommended that the link length not exceed 2 in a functional implementation. At the same time, we should also pay attention to the interdependence between systems, and pay attention to this point, which is a risk point for system stability.

Cost Quantification:

Based on the analysis of the above three aspects, the sorted out deliverables: 1. The context dependence of the system; 2. The business domain definition and capacity planning map of the system. 3. The length of the application call link and mutual dependencies; 4. The assessment of the rationality of application split granularity; 5. The sinking or merging of capabilities in the system; 6. The list of systems with less business volume.

Among them, 1-4 can be regarded as the action guide or principle of the system, and 5-6 is the next step of action. More simply, it is the shutdown and restart of the system that we often do. When the system of the business department is shut down and transferred, it is also necessary to consider the cost issue and do a good job of quantifying the cost.

First of all, it is necessary to evaluate the cost of shutting down and switching over, and secondly, to evaluate the cost of daily maintenance of the system for 1-3 years, including the cost of manpower and machine resources. The three-year cumulative value of the former and the latter is subtracted. If it is greater than zero, the system It is recommended not to move for the time being, if it is less than zero, the plan of shutting down and turning over can be considered.

The above are my thoughts on the rationality of the system architecture from the perspective of R&D.

If the rationality of the architecture is evaluated from a business perspective, it may become the following three aspects: First, it can solve current business needs and problems. 2. Efficiently complete business requirements: It can solve all current business problems in an elegant and reusable way. 3. Forward-looking design: It can satisfy the business in the second way for a period of time in the future, so that it will not cause earth-shaking changes in the structure every time the business evolves.

Different perspectives necessarily mean that everyone has different views on the same thing.

Author: Jingdong Retail Gao Tianlin

Source: Reprinted by JD Cloud Development Community, please indicate the source