Application Software hierarchy

When talking about application layers, we usually talk about two levels: Logical layers and deployment layers ). These two levels have different purposes, so there are also some differences in the way they are divided, which can bring different benefits to applications.

Logical hierarchy

The most important purpose of layer division isAdjust the dependency between different parts of the application. Applications can be seen as a collection of data and business rules, which interact with users through the user interface. If you do not divide the layers, or just divide the simplest layers, the system structure will be like this: the database is in the center of the system, on which the user interface is created, business Rules are written in the user interface.

The problem is that the database is not suitable as the center of the application, because the database is only responsible for storing data, rather than interpreting the data (this is a task of business rules ), the business rules are scattered in a non-central location, with scattered expressions on the user interface. Once the demand changes, the business rules must change accordingly, and the business rules are scattered everywhere, so we need to look for and modify the business rules. As applications expand, this is a very difficult task.

To solve complex dependencies, we have created a business layer. A typical logical hierarchy is: presentation layer-> business layer-> data layer.

The method for establishing the business layer can be very simple: if our applications need to carry out multiple businesses, we analyze the business processes, find out the common parts of these processes, and extract them as independent processes, this forms the simplest business layer. In this way, the Code of Business Rules can be reused between different interfaces to solve the irrationality of dependency. This is a process-based method. However, this method has two problems:

First, based on his full understanding of various businesses in the system, he must correctly analyze the details of various business processes. Otherwise, there must be omissions in the process division and the common process extraction. However, in the actual development process, we often only understand the overall business situation at the beginning, and gradually understand the details. Some hidden relationships must be recognized during development. Sometimes some specific development technologies will affect the implementation methods of some businesses and affect their processes. This makes process analysis very difficult.

Second, process-based methods are greatly affected by changes in demand. This analysis method is based on the business process rather than the purpose of the business. When there are business changes in the system, it will affect other businesses with common processes. The dependency between businesses is serious, and the adaptability to demand changes is poor.

If you use an object-oriented method to abstract the business and summarize the methods required to implement these businesses (for example, you need to update data tables, send commands to the port, and maintain the status of the business ......), Develop a unified framework for all businesses, it is up to this framework to determine the business execution Policy (how to limit the business conditions, what steps should be taken, whether to retry or give up upon failure, and when to report the progress of business execution to the user ......), The framework does not support all services. When a user executes a business, we only need to create a business object and place the object in the framework to monitor the execution progress. In this way, the implementation of each business is naturally isolated, and the dependency is relatively simple. At the same time, it is easy to cope with changes in demand. If you modify a class and the execution methods of multiple businesses need to be changed, you can find a solution on the framework.

If a new mechanism is added for this framework, it not only executes business objects, but also creates and destroys business objects, bringing more powerful functions. The business framework becomes a business container. When a user wants to execute a business, we can ask the Business container to create this business object. The business container can give us a proxy of the Business Object to hide the real object location. The actual execution process may be distributed. Containers manage the transaction of business objects for us, save the progress of business execution, suspend the business when necessary, and start again after the conditions are met, destroy the object after the business is completed ...... We don't have to worry about this. containers are used for us.

Optimizing the dependencies within an application is an important purpose of dividing the logical hierarchy. The Calling mechanism between layers can be called layer by layer or cross-layer, which is a common method. The dependency direction between layers can be from top to bottom, or from bottom to top, which is reasonable. Be careful that the two layers cannot generate mutual dependencies; otherwise, the hierarchy will be damaged. For example, there are two levels of A and B, either A depends on B or B depends on A, and cannot depend on each other. If there must be inter-layered calls, some methods must be used to convert the dependencies in one direction (such as delegete, interface, message, and event ). There should be no circular dependency between multiple layers.

Deployment Level

The purpose of the deployment hierarchy (tier) division isEnhances Application Deployment flexibility and makes greater use of hardware environment resources.. Application Software has a wide range of requirements for the environment. For example, the data storage module requires strong server stability, fault tolerance, and high IO efficiency, the transaction processing module requires a fast computing processor and a large memory, while the management terminal requires strong performance. It is usually difficult to have such a server to meet various needs. Therefore, we need to divide the application into multiple layers and deploy them in different locations.

At the same time, some applications need to access some sensitive data, which is not allowed or impossible to be centralized locally, which requires more flexibility in deployment.

From the perspective of system performance, applications can be reasonably divided during deployment to increase system scalability. When the existing hardware conditions do not meet the requirements, you can change the deployment mode to improve the system performance.

For example, when a server is used, it can satisfy 100 concurrent businesses. When the number of concurrent businesses reaches 150, it can be met by adding servers. This requires the application to use a multi-level structure, and it is impossible to perform such expansion without the necessary layers.

For another example, we need to create a system that supports 100 clients on a database that supports 20 connections. In this case, we must establish a database-independent connection persistence level.

Application Deployment layers have some common modes, such as B/S structure, C/S structure, and client/Application Server/data server structure. The specific mode depends on the needs of the application. If the application needs to frequently access the customer's local resources, it requires high efficiency or powerful offline processing functions, the B/S structure is not suitable, and the C/S structure is a good choice. If deployment and configuration are relatively simple and different client environments are required, the B/S structure is a good mode. If you need to create a server group to balance the load, the application server is essential.

There is a certain relationship between the deployment level and the logic level. For example, if a program is logically not hierarchical, it is difficult to divide it into multiple layers during deployment. However, these two layers do not have to be strictly consistent. For example, using the deployment layer of "client/Application Server/Data Server" does not necessarily mean that the client corresponds to the presentation layer, the Application Server corresponds to the business layer, and the data server must be the data layer. The corresponding relationship cannot be absolute. There is no strict correspondence between the two levels. They are divided for different purposes.

For example, in some software systems, business logic is directly written in the database in the form of stored procedures. In such a system, the business layer corresponds to the data server. If such a business layer is well processed, it has clear and concise logic and is easy to maintain. However, the deployment will obviously lose flexibility.

Real problems

Many people often experience this in software design: when designing a software architecture, in order to simplify the logic complexity of the software system, A common approach is to divide a large system into several layers. A common method is to break down the functions of a large system and deploy them in multiple components. Each component only performs a single function to reduce the complexity of the component. Components use some weak coupling methods for communication, such as messages and TCP connections.

However, in the actual development and maintenance process, it is found that this does not reduce the complexity of the system. Although parts have been physically separated and run on different threads, processes, and servers, there is a strong logical coupling between parts, the interfaces between parts have complex time-and space-staggered relationships. The caller needs to call the interfaces of the called according to the complex logic order to save the statuses of each call, go deep into the business process details of the other party. The structure of the system is not concise because of the hierarchy, but more complex. A business change may have an impact on multiple levels. The cost of the change is even greater, and it does not play a role as a hierarchy model.

The reason for this is that the designer obfuscated the differences between the logical and deployment layers. For the purpose of reducing the complexity of the system, the first point is to logically separate the layers, so that each layer can process the business at a different abstraction level. Establish a reasonable abstraction layer for business behavior, instead of simply letting each component execute a certain stage of the business, or simply letting component A execute ABC business, and component B execute XYZ business, this is the key to the logical hierarchy. This can reduce the complexity of the system. Wrong logical hierarchy can only make the system more complex. The Blind division of deployment layers is unrelated to the initial purpose and can only increase complexity.

The role of hierarchical deployment is not to simplify the logical structure of the system, but to increase the adaptability of the system to the environment.

The design at the logical level and the design at the deployment level are often intertwined in software development. They are mutually constrained, mutually influential, and share common features. However, these two levels are essentially different, and there are opposing aspects. developers need to coordinate during design, which also requires attention.