Logical hierarchy of software

Basic Level

The logical structure of the software can be divided into the following four basic layers:

From the bottom up:

1: infrastructure layer-this layer is purely a technical layer that solves physical problems of the system, such as database gateway, network communication, and object containers ...... This part has little to do with business requirements and is the physical condition of the system.

2: business Objects-at this level, business elements have emerged, and the concepts in the business field are implemented here. For example, the system of a shipping company should include routes, flights, seats, passengers, boarding passes ...... These objects should have attributes and methods that match the actual business fields.

3: business Process-this process does not refer to the process in which the program solves the problem, but to the user's business activities. It represents an end-to-end business process. For example, the ticket reviewer applies for a boarding pass for a passenger. The input parameters of a business process are business objects, and the output parameters are business objects. Exceptions are also business objects. Business Objects are combined and connected in a string to automate business processes. This layer directly meets user needs.

4: UI and interface-call the business process at this level and deliver the execution result to the software user or another system.

This type of logical hierarchy is the most basic situation, and various complex layers are expanded in this way. For example:

A dao layer is added between the infrastructure layer and the business object. On the one hand, the DAO layer is responsible for data storage, reflecting the data storage method and the properties of business objects. In this way, the business object only needs to be responsible for pure business logic and does not have to worry about physical issues. Simply put, you do not need to write SQL statements in business objects.

A Service layer is added between a business object and a business process. Business Objects are also behavioral, but such behavior is relatively subtle. The caller needs to maintain the necessary State between multiple calls and use the Service layer for encapsulation, more clearly express business meaning.

Unit Test

Unit tests need to focus on the dependency between layers. To test an object at a certain level, you must create each object on which it depends. The simpler the dependency between layers, the easier the test.

In principle, logical layers are dependent from top to bottom. Objects within the same level can depend on each other. Cross-layered calling is also allowed, for example, calling a Business object in the UI Process. There is a dependency between the UI Layer and the UI Process layer. During development, we most want to test these three layers: business process, service, and business object. We only need to create a stub object for the lower-level objects, and we can test the objects at these three levels.

The test results at these three levels not only ensure the correctness of the program runtime, but also test the Business Process of the program. During development and maintenance, a business process has changed. You can use unit testing to ensure that other processes are not compromised. This architecture ensures the iterative development process.

Integration with physical layers

All of the above are the logical layers of the system. There is another physical level in the system. The purpose of the logical hierarchy is to simplify the logic complexity of the program and facilitate development and maintenance. The implementation of the physical hierarchy needs to consider the actual physical distribution and reasonably arrange tasks on each physical node, maximize system performance. The division of logical and physical layers is based on and for different purposes. There is a link between them, but it is not absolute.

There are two ways to combine logical and physical layers:

1. Solve the physical distribution problem at the infrastructure layer, create a distributed object container, and put business objects and services in the container. In this way, business Objects and services do not have to deal with complex physical distribution issues, and business processes do not have to worry about where the called objects are created. This approach minimizes the impact of the physical structure on the logical structure of the program and increases the flexibility of the physical distribution. However, in most cases, system efficiency is compromised.

2. Handle physical distribution issues within the business object, or develop a technically unrelated interface to reflect the business object, and write their respective implementations on each physical node. In this way, the physical and logical layers are stirred up, so that the logical structure of the system is chaotic, but the operation efficiency can be achieved.