System Architecture Reconstruction

Next, we will look at the "bad taste" in the system architecture and design (note: "Bad taste" is one of Martin Fowler's
Concept), respectively summarize some "Reconstruction Modes", to see how these models remove the "bad taste" of these designs.
1. Rename an object
Problem: The system composition elements (subsystems, components, modules, etc.) defined during the architecture and design are named
Chaos makes the system structure hard to understand because it cannot express the purpose or semantics of the system element. In fact, a shelf
During the development of the architecture, the name gradually becomes chaotic, which is an important reason for the aging of the architecture.
Solution:
Use pre-defined naming rules and encoding rules within the global scope of the system.
Try to use a name containing clear semantics that is easily understood by project personnel to name system elements.
When changing the name of a system element, you must consider the reference relationship between the element and other system elements to make the element name
Contains the referenced concepts.
Example:
During refactoring, we can use appropriate names to express the relationship between two components or services, as shown in.
2. Transfer duplicate elements
Problem: In system architecture and design, the same function or system element has repeatedly appeared in many other system elements. This
This will reduce the comprehensibility of the system and spread the Code with the same functions throughout the system design, regardless of
Or coding, it will undoubtedly increase the complexity of understanding and maintenance.
Solution: some shared system elements can be encapsulated based on the object-oriented "encapsulation" principle,
This facilitates the reuse of other parts of the system. At the same time, such architecture and design will make the system structure description more simple and straightforward
. What we need to do is:
Identifies public functions or common tasks distributed in the system structure.
Summarize the system elements that take advantage of these common components.
Try to transfer these shares from each system element to an encapsulated system element.
In other words, we can use a new component to encapsulate shared functions and remove the same
The design logic is replaced by the calling method to meet the function reference of each component.
3. Use abstract hierarchies
Problem: During architecture restructuring, we will find that some design units have very similar functions. These repeated occurrences
Similar Design Units and subsequent code with similar functions will seriously interfere with the consistency of some concepts of the system architecture, thus
This reduces the simplicity and readability of the architecture description. Further, it may cause system calls to be tight with various object variants.
Coupling to form an insurmountable design structure.
Solution:
To maintain consistency between the system architecture and similar concepts in the design, we should consider using data abstraction to make objects
Form a natural hierarchical relationship between them. Note that the famous LSP (liskov substitution) of Barbar liskov
Principle, replacement principle). The original expression of this principle is: to use a pointer or reference a base class function, you must
You do not need to know the object of its derived class. The general solution is as follows:
Using LSP as the guiding principle, a "general abstraction" is introduced to encapsulate similar general functions.
Defines a hierarchy based on "General abstraction.
The architectural design units of other specific variants are derived in sequence according to the hierarchy.
For example, in the. NET architecture, each control requires a set to record the reference of the next control.
According to the LSP principle, abstract hierarchies with combinations of features can be formed to derive other specific elements, such
.
4. Mediation is replaced by adaption)
Problem:
During architecture restructuring, we will find some situations where the centralized design is excessively used. When the intercommunication between peer system entities
When the mutual order is complex, it is a good choice to use some mediator appropriately. However
Yes. In this way, the centralized management architecture has a significant restraining effect on the scalability and scalability of the system. Because
To add a new system entity, we must modify a series of mediator, which is obviously
This is not conducive to system maintenance.
Solution:
The following methods can be used to replace the Centralized Management Mediation System Design:
Add a "system integration layer" in the system architecture. The system entity (such as component or service) is completely
Plug-ins are integrated in this "integration layer.
Transfers the calling logic of these peer entities to other system code locations beyond the integration layer.
Through the system integration layer to call the corresponding components or services.
For example, the architecture design of the mediation mode is converted to the adapter mode, which significantly enhances the scalability of the system, as shown below:
Figure.
5. Merge subsystems
Problem:
During architecture reconstruction, we often see tight coupling between subsystems in a system. Based on height
The principle of low coupling of cohesion, in which each subsystem in a system should maintain relatively loose coupling during Architecture
In addition, each component in a subsystem can maintain a tight coupling relationship. If the coupling relationship between subsystems is too large
High, the cost of system maintenance and modification is very high for the overall system architecture, and the reuse of a sub-system is also
It will become very difficult. This is entirely due to tight coupling that results in a complex relationship between subsystems.
Solution:
There are some subsystems in a large-scale system. These subsystems are more or less coupled with each other. Two
This tight coupling relationship between subsystems actually means that the two collaborate for the same purpose. In this case
To consider merging these two subsystems.
For example, it is better to merge tightly coupled subsystems into two subsystems. This is in line with "loose coupling between subsystems, sub
The design principle of system tight coupling.
6. Strengthen inter-layer calls
Problem:
If we reconstruct the system, we often find that inter-layer invocation occurs. The emergence of this design is completely
It breaks the advantages of the layer architecture style and can easily cause architecture confusion.
Solution:
Currently, the system architecture often adopts the layer architecture style. Such a layered structure is very suitable for splitting system functions,
The system structure is clear to facilitate future maintenance. When an over-layer call occurs, you need to re-build the inter-layer relationship,
The system maintains a strict layer-by-layer calling architecture.
Note: It is not very easy to solve the problem of over-layer calling. Sometimes, you even need to reconstruct the business logic to solve the problem.
.
7. Replace remote method call with message communication
Problem:
When restructuring the system, we often find that a large number of remote method calls (RPC, Remote Procedure Call) are used in
It is undoubtedly the most common communication implementation method. Even at the front-end application layer, an asynchronous
But the implementation of the backend communication layer is usually implemented by RPC synchronization.
However, in a distributed system, if event-based Asynchronous communication is required, the optimal communication mechanism is still
Message-oriented middleware.
Solution:
Asynchronous Communication in Distributed Systems is a very favorable communication mechanism. System Communication Mode from synchronization mechanism to truth
The transformation of the positive asynchronous mode can be reconstructed using a gradual approach: synchronous communication is still required for the existing system.
, Retain this architecture. At the same time, add a "message middleware layer" in the system architecture to allow asynchronous messages
The communication transmitted is switched to the message middleware layer.
For example, the two modes coexist and will be gradually changed
It depends on the asynchronous communication mode of the message middleware layer.
8. optimize resource utilization in cache Mode
Problem:
When restructuring the system, it is often found that there are serious problems with the system performance. Further analysis shows that the system performance
The bottleneck is that a large number of system entities frequently access a shared resource. Because every time resources are accessed
A series of performance-consuming actions such as Resource Creation and allocation. If resource access efficiency and system performance are improved
This can be significantly improved. This is of great significance in the design of some real-time systems.
Solution:
There are often many shared resources in the system. optimizing resource access as much as possible is a way to overcome system performance problems.
Important Means. Use caching to cache resources with high utilization, and define an appropriate resource allocation principle to make
Each entity in the system can share the cached resources. For real-time systems, the so-called memory-based database"
Is a widely used method.
For example, the sub-system consciously stores frequently accessed resources in cache with high access speed.
To avoid resource creation, which consumes system performance. Let's take a look at three types of data access
Question form, and compare their advantages and disadvantages.
9. Avoid expansion of component interfaces
Problem:
In reality, a software application often uses Abstract methods such as interfaces to make
Function abstraction meets various application requirements. A system that has been maintained for several years. With the addition of new functions
The Component Interface also changes, which leads to the expansion of the component interface.
An interface design that meets various requirements will significantly reduce the availability, maintainability, and manageability of the system.
The most serious case is that such an expanded interface may cause confusion in system code.
Solution:
We must acknowledge the fact that the interfaces of components will expand. You can consider introducing
Enter the hierarchical relationship of an interface, and then provide a public interface navigation method, so that the client code can
Find the corresponding function implementation in the hierarchical interface relationship.
For example, you can reconstruct an expanded Component Interface into a hierarchical structure and provide a navigation machine to find specific functions.
As shown in.
10. structure and design symmetry of cages
Problem:
In the preliminary design of the system, we often see that the Message Processing Mechanism of Some subsystems is to use the "Observer
Computing mode, linking messages with message processing. However, some subsystems use hard code
Use the judgment code to encode the message and message processing. Some component designs only take care of Resource Acquisition
But no resources are released after the component task is completed. These are the so-called "asymmetry" that we often see in reality"
Architecture and design method.
A well-balanced system refers to a system that uses the same
Architecture concepts and design techniques to solve similar problems. This symmetrical structure is very important for maintenance personnel to understand the system structure.
Yes. On the contrary, if a system uses asymmetric architecture and design, it will often lead to confusion of the system concept, thus
Subsequent Maintenance is very difficult.
Solution:
If the system architecture is symmetric to organize the structure and relationship in the system, during system maintenance
The method is as follows:
During system restructuring, you must first identify the design choices at the strategic and tactical levels in the system.
Summarize the background of these design choices into a category. And then consider using the same type of design choices
The same architecture principle or design means.
For example, the design choices of similar backgrounds are summarized and the same observer mechanism is used for event distribution and
Processing. It may be a more symmetrical method.
Software refactoring is an optimization process of the architecture and a sensitive and risky process.
Small steps forward and solve only one problem at a time, and gradually optimize the architecture.