After defining the Architecture Vision, all the team members should have a certain understanding of the developed software. But what should we do next in the face of a huge software system? The idea of divide and conquer is a very important idea in the computer field, so we can start from here.
To design application software, layering is a very important idea. Mastering the idea of layering can be pleasing to the eye. Due to the importance and particularity of this chapter, the content of this chapter is divided into the upper and lower sections and does not adopt the mode to describe the language.
Layering is only a way to effectively organize the system. This chapter focuses on enterprise applications, but most of the content can be applied to other systems or for reference by other systems.
In enterprise applications, there are two very important concepts: business logic and persistence. It can be said that enterprise applications are carried out around the business logic. For example, reimbursement, order placement, and goods warehouse receiving are all business logic. From the underlying implementation of business logic, business logic is actually the process of organizing business entities. This is only true for an object-oriented system, because in an object-oriented system, it is very basic work to identify business entities and formulate the behaviors of business entities, the combination of different business entities forms the business logic.
Another important concept is durability. Most of the data in enterprise applications must be persistent. Therefore, it is very important for basic organizations to support persistence. Currently, databases, especially relational databases-RDBMS, are the most common persistent mechanisms.
In addition, there are other important concepts in enterprise applications, such as human-computer interaction.
In order to organize various logics in an enterprise more effectively, we use layer technology to implement enterprise applications. The layer technology has a long history in the computer field, and the concept of hierarchy is referenced in the computer implementation. The layer-7 protocol stack of TCP/IP is also a typical concept of hierarchy. The advantages of layering are:
The upper-layer logic does not need to understand all the underlying logic. It only needs to understand the details of the layer adjacent to it. We know that the TCP/IP protocol stack uses different layers to package data layer by layer, and the coupling between different layers is significantly reduced. Through strict hierarchy, the coupling between layers is greatly reduced.
The lower layer of a certain level can have different implementations. For example, the same programming language can run on different operating systems and machines.
Similar to article 3, the same level can support different upper-level layers. TCP supports FTP, HTTP, and other application layer protocols.
Based on the above considerations, we divide enterprise applications into multiple layers. Enterprise applications should be divided into several levels. At present, there is no unified opinion.
In software development in the past few years, the two-layer structure plays an important role. For example, large host/terminal methods and Client/Server methods widely used in banks. The two-layer architecture still exists widely until now, but the two-layer architecture has many disadvantages, such as high client maintenance costs and difficulty in distributed processing. With the addition of more layers between two-layer end users and backend services, the multi-layer structure emerges.
The classic three-tier theory divides applications into three layers:
Presentation Layer (Presentation Layer), used to process human-computer interaction. Currently, the two most popular presentation formats are Windows and WebBrowser. It is mainly responsible for processing user requests, such as mouse clicks, input, and HTTP requests.
The Domain Logic Layer simulates the actual activities of an enterprise. It can also be considered as a model of enterprise activity.
A Data source Layer that processes databases, message systems, and transaction systems.
In practical applications, the layer-3 structure has some changes. For example. in the. NET System, applications are divided into three layers: Presentation Layer, Business Layer, and Data Access Layer ), it corresponds to three layers in the classic three-layer theory. It is worth mentioning that the presentation layer in the. NET system can directly access the data access layer, that is, the record set technology. In ADO. NET, this technology has been very mature and is very friendly through some data sensing components in the presentation layer. This layer-crossing access technology is generally considered not allowed because it may damage the dependency between layers. In Windows, strict adherence to the rules requires a large amount of additional work. Therefore, we can see that the Principles are not static.
In the J2EE environment, the layer-3 structure evolves into a layer-5 structure. In the Presentation Layer, J2EE divides it into the user Layer running on the Client and the Presentation Layer running on the server ). The main reason for doing so is that Web Server has become a very core technology in J2EE, such as JSP and Java Servlet. The Web layer provides the presentation logic for the user layer and responds to user requests.
The Business Layer is still the core logic for processing applications. The data Layer is divided into two layers: Integration Layer and Resource Layer ). The resource layer is not a concern of J2EE. It may be a database or other old systems. The integration layer is an important layer, including transaction processing and database ing systems.
Instance
The organizational structure of this chapter is different from the previous model. Let's start with an example to understand the importance of hierarchy in architecture design.
Is a software architecture diagram of a business processing system. In, we divide the software into four layers. This hierarchy is similar to the J2EE hierarchy we mentioned earlier. However, unlike J2EE, a Web Server layer is missing because we do not need any Web Server at present.
On the resource layer, we have three types of resources: database, platform service, and UI. Databases are the foundation of enterprise applications. Here, the Platform service refers to the functions of the Transaction Manager provided by the operating system or third-party software. It is worth noting that the transaction manager here refers not to the transactions supported inside the database, but to the transaction processing between different business entities, which is of great significance to enterprise applications. For an enterprise application, cross-module, cross-software, or even cross-platform sessions are often required. At this time, transactions simply supported by databases are often unable to be competent. Examples include the MTS of Microsoft and the DBLink of Oracle. Of course, if you can use database transactions to process most sessions in your system, you can avoid this design. In addition to the typical transaction manager, the platform can also provide other services. Most enterprise applications are integrated with multiple platform services. Platform services are crucial to architecture design. However, from the perspective of hierarchy, the upper-layer design should be as unrelated as possible to the platform. Like using platform services, enterprise applications generally do not design interfaces from the ground up. In most cases, existing UI resources are used. For example, the interface section in the Window platform MFC. Therefore, we also classify the used UI resources into the resource layer.
The upper layer of the resource layer is the integration layer. The integration layer mainly completes two tasks. The first is to use the platform service of the resource layer to complete the transaction management in the enterprise application. Some transaction processing mechanisms have provided a better encapsulation mechanism, so you can directly use the platform services at the resource layer. However, for most applications, the services provided by the platform are often relatively simple. At this time, the integration layer is very useful. The second is to provide a persistence Mechanism for the objects on the previous layer. It can be said that this is a set of transitional objects. It actually uses the database functions at the resource layer and provides services for objects at the previous layer. In this way, the business objects at the previous layer do not need to deal with the database directly. For systems that use relational databases at the underlying layer and use object-oriented technology in programming, the most common method to deal with persistence is object/relational ing (OR Mapping ).
At this level, we can make some extensions to analyze the role of the layer. Assume that our system needs to process multiple databases, but there are some differences in the processing methods between different databases. At this time, the role of the layer is displayed. We support processing of multiple databases in the integration layer, but provide unified interfaces for the layers above the integration layer. For the business layer, it does not know or need to know the differences between databases. At present, we have developed our own persistent classes in the integration layer. However, with the expansion of functions, the original classes cannot support new functions. The new solution is to purchase commercial programs. To minimize the impact on the business layer, we still use the original interface, but the specific implementation is different. The new Code is implemented for new business programs. For the business layer, the ideal situation is that no changes are needed. Of course, it is unlikely that such a good situation will happen in reality, but it is certain that the introduction level is much better than the non-Introduction level.
The two examples listed above are a good solution to the coupling problem. We will discuss the Coupling Degree in the hierarchy below.
The design of the business layer is relatively simple. Currently, it is only implemented as a group of business classes. Similarly, the presentation layer is not designed for more processing. Classes in the presentation layer inherit from the resource layer. This is a way to deal with it. Of course, it can also be the relationship of use. This is related to the specific implementation environment and the preference of the designer. It is not the only way to do this. After a preliminary understanding of the general architecture of the software, we need to further explore the requirements to refine our design. In the previous design, our design for the business layer was too rough. There is still an old system in our application that implements application rules. From the application perspective, these rules are still in use, however, new rules will be added to the new system. After the new system is enabled, the Rule Processing in the old system still needs to play its role, so it cannot simply transfer all rules to the new system. (Sometimes we want to save costs rather than implement the logic of the old system in the new system ). We will add support for new requirements in the refined Architecture Design Process in step 2.
In the process of refining the business layer, we still use the layer technology. At this time, we divide the original business layer into two child layers. For most enterprise applications, the business layer is often the most complex. There are intricate links between enterprise objects, and these seemingly independent enterprise objects need to be used in enterprise processes. We hope to introduce a new mechanism in the business layer to organize the business class. Organizations at the business layer need to rely on specific application environments. There is a huge gap between the application of the financial industry and the application of the manufacturing industry. Here, we look at our design from the perspective of general design thinking:
First, we can see that the business layer is reorganized into two layers. The primary consideration for adding layers is the reusability of the design. We know from our previous knowledge of the layer. A higher level can reuse a lower level. Therefore, we classify some classes in the business layer into lower layers for higher levels of use. The main idea of reducing the class hierarchy is to break down behavior, identify common behavior, and extract common behavior.
In the analysis mode of Martin Fowler, a method is provided to separate the operation layer from the knowledge layer:
Action, Accountability, and Party are high-level Operational layers, which are specific to specific applications. However, observing Accountability and Party has many similar responsibilities. That is to say, our knowledge processing is not suitable. Therefore, Martin Fowler proposed a new level-a lower level of Knowledge Layer ). Reusable knowledge in the operation layer is organized into the knowledge layer. This allows you to extract the commonalities of the operation layer. Note that although the concept of Level in the graph differs from that of Layer, the idea is basically the same.
Another layered method is to use inheritance:
This figure also comes from the analysis model book. Different departments have differences and commonalities. Extracting commonalities into the parent class is the basic concept of inheritance. At this time, we can regard the parent class as a lower level, and the Child class as a higher level. For a group of classes with deep hierarchies, you can also separate hierarchies from a certain horizontal line.
The last method needs to break down and abstract the behavior of the object. In C ++ STL, Iterator is implemented for different data types and containers. Its implementation is a typical behavior to reduce layers. We do not consider its support for different data types, because it uses a unique Template technology and only considers its implementation for different containers. The first is the analysis of commonalities. Whether it is an Array or a Vector, the traversal operation requires three conditions: container start point, container length, and matching value. This is an abstraction. In this way, you can unify the interfaces of different containers.
We have discussed the benefits and implementation strategies in detail. Next, let's go back to the components in the layers.
A business entity refers to individual objects in an enterprise. Such as orders, customers, and suppliers. Because business entities can be used by many business processes (business sessions), we place business entities in the business entity layer. Most business entities in an enterprise require persistence. Therefore, in our design, the business entity delegates the persistent responsibility to the persistent package in the next layer, rather than directly calling the database method. Another common method is to use inheritance-the business entity inherits the self-persistence class. Entity Bean in EJB is a typical business Entity. It supports automatic persistence.
In our system, rules are embarrassing. Some rules are in the old system and use the persistence mechanism of the old system. New rules must be supported in the new system. For upper-level users, you do not need to know the rules of the new and old systems. It would be silly to make a new and old rule judgment when using the rule and call different system functions. Our design should be transparent to the upper layer.
Therefore, we have designed three packages to implement rule processing. The wrapper wraps the rules in the old system, so it is considered in the following aspects: first, the old system is process-oriented, so we need to use the wrapper to convert the function (or process) encapsulate it into a class. Second, the use of the old system requires the support of additional programs (or platform services), so a separate class is required for processing. Finally, we can use the Adapter mode [GOF 94] to unify different interfaces of the new and old systems so that they can work together. The new rule class implements new rules. A better practice is to define a virtual protocol. The specific manifestation can be a virtual base class or interface. Then, its sub-classes Implement Virtual protocols. Then, you can combine the methods described earlier to convert the interface of the old rule to the new interface to unify the Rule interface. We can see that business entities need to use rules. Through a unified interface, business entities can use the old and new rules transparently.
After defining rules and standard rule interfaces, the rule controllers at the previous layer can call rules to implement different rule combinations. Therefore, this rule controller is similar to an application rule. In business transaction processing, you need to call the rule controller to implement some functions.
Please note that although the ideas discussed here are very simple and clear, they are not so easy to handle in reality. It is too difficult to create a unified interface for the new and old rules. It is even more difficult to make the interface relatively stable in the future. After the application has been deployed, any small changes to the released interface mean a high cost. There is no good strategy on this issue, and experience is the most important. In practice, a more practical method is to add some additional parameters to the interface. Even if it is possible that this parameter is not currently used, add it if it is possible to use it. For example, for commercial application software, databases, or relational databases, must be indispensable. A large number of operations need to be combined with the database. Therefore, you can consider adding a database connection string parameter to the method. Although this is not necessary for many methods, it provides a scalable space for future practices. The design of a well-known ERP software in China adopts this idea.
The main focus of this chapter is on instance research. With a basic concept, we will come back to discuss some of the principles and issues that need attention.
(To be continued)
Author profile:
Lin Xing, Senior Project Manager of the Project Management Group of Chen Xun software studio, has many years of project implementation experience. Chen Xun software studio is committed to the application of advanced software ideas and software technology. Its main research direction is software process ideas, Linux cluster technology, OO technology and software factory model. You can contact him by email iamlinx@21cn.com.
