Reflections on the re-drawing of business travel logic architecture

Business department unification is three years, the system from the initial construction to smooth operation, architecture experienced many times the reconstruction and collation. Look back, tidy up the system, and talk about your own thoughts on the design practice of the logical architecture.

The logical diagram before and after the business travel system is as follows:

This chart is the business travel system of the latest finishing system logic diagram, compared with the original, there are more interesting places, worthy of evaluation.

The clarity of the layered architecture.

The original three-layer layered architecture is still retained, and a further abstraction has been made, such as the System management platform and the job Platform subdivision content is not displayed; The application of Service Layer CC subsystem framework is blurred, the CC job platform is defined as the channel Terminal system, and its service layer and support layer are the internal technical architecture of the subsystem. It is not shown in the overall logical architecture diagram; The external and business system-owned services are properly merged; The data layer is almost completely redefined. Due to the large system and the large number of subsystems, in each layered class, the appropriate topic and the division, these changes make the logical architecture for the hierarchy, subsystem, module responsibilities clearer.

The essence of the use layer is: 1) The large logical structure of the system is organized into independent, responsibility-related discrete layers, clear, cohesive, and concerned about the separation; 2) collaboration and coupling are performed from higher to lower layers, avoiding coupling from lower to higher layers.

The use of layers helps to solve the following problems: 1 The change of source code affects the whole system; 2) application logic and interface display are intertwined, difficult to reuse and distribute; 3) technical logic and business logic are intertwined, difficult to reuse, distribute and replace, 4) high coupling between fields, Difficult to define and assign tasks clearly to different developers

On the pros and cons of stratification has always been debated, here do not repeat. Knives can hurt people can also help others, the key to see how to use. Architectural design, the use of layering is to help further understand the system, is to achieve the purpose. The subsequent logical architecture diagram also needs further refinement. Hierarchy within a box represented by the sub-system, the thickness of the particle size is roughly equivalent, but there are some more coarse can be further expanded, such as the operating platform and web site, the scale is relatively large, can again horizontal stratification; Business data, such as databases, can be vertically divided by the schema.

Data-tier issues.

The data layer has more new things than the architecture diagram, and the most frequently changed places are the most problematic. Many of the problems with databases during the run process are associated with the logical schema design in the following few.

The first problem is the division of Business and non-business data, and the definition is not clear enough, that is, the vertical hierarchical planning of data. This may be due to the relationship between the organizational structure of the project, we are Group development, each development team according to their own experience and habits of business data and non-business data decomposition and storage, as well as the Public data Reference, association and mapping, confusion, so that in the database this block has a lot of related knot.

The second problem is that the separation of file data, cached data, and report settlement data is omitted in the partitioning of the data layer. The first is the file data, development, testing process is a single point, and deployment is multipoint, so many files stored in the application server can not be shared by other nodes, and then access to the way some are read through the stream, and some through the HTTP site access, There is also a need for special file synchronization tools to synchronize files between the front and rear terminal systems. These processing is too complex, resulting in operations colleagues often reported that the xxx file is not open, or can not be downloaded. The separation of the cache and the report, the Clearing House is related to performance, the initial design of the neglect, so everyone in the development, the complex low frequency and the need for long-running business logic and simple logic together into the main library, the peak business hours will lead to CPU consumption reached 100%, consumption of hardware resources, Thus affecting normal business operation.

Collaboration between responsibilities.

The logical architecture cares not only about dividing the system into different parts, but also about how the parts interact. It is the key point and difficulty of logical architecture design to identify collaboration and abstract common mechanism. The previous diagram does not describe, from the latest figure, the channel layer and the service layer, through the remote call, walking is the Hessian protocol, the service layer and the data layer is a method call, the use of JDBC and other middleware technology. The separation between layers and layers is relatively clear. In the actual running process, the service layer of the various subsystems, also need to call each other, the data layer of the Unit also has a synchronization of data links, the internal layer of collaboration, more difficult to abstract the new connector logic unit, the current common method is if there is a cross-call, continue down to the data layer. For example, marketing and customer two services need to call each other, then often entrusted to the storage process implementation, layering and separation of difficult to reconcile the small part of the logic, put in the database implementation to solve, take a balance.

About logical architecture design.

Logical architecture is to describe the relationship between responsibility and responsibility of the system, which is the macro-structure of software. This is called a logical schema because it does not determine how to deploy these elements on different operating system processes or on computers that are physically on the network.

The thickness and granularity of the layers and subsystems need to consider the characteristics of the system under construction. Depending on the size of the system, the logical structure can be as large as a hierarchy or a subsystem, or as small as a module or a class. But no matter how it is divided, the main components of the system need to be focused on the responsibilities of cohesion. You also need to describe the hierarchy of invocation principles, such as higher layers can call lower layers, or vice versa.

In a strict hierarchical architecture, a layer can only invoke services that are adjacent to it, and are typically used for network protocol applications. In an information system such as business travel, we adopt a more relaxed layered architecture, and the higher layers can invoke services at any of their tiers.

The best source of logical architecture is use case analysis. The use case-based analysis method will make the design of the logical architecture become orderly--by analyzing each critical use case logically, the use case is implemented as a specific combination of functional blocks, and finally, the results of these use case analysis are combined into the logical architecture of the whole software system. But before the use case analysis method produces, the function module's determination somewhat has some "the hard" to think out the flavor, especially does not directly carry the business function The module sometimes is more easy to omit, until the large-scale programming realization stage only then discovers.

Reflections on the re-drawing of business travel logic architecture