Test Architect: Layered architecture of software architecture patterns 2

Example

To demonstrate how the layered architecture works, imagine a scenario, such as Table 1-4, in which the user sends out a request to get the customer's information. The black Arrow is the request stream that obtains the user data from the database, and the red arrow shows the direction of the return of the user's data. In this example, the user information is made up of customer data and an array of orders (orders placed by the customer).

The user interface accepts requests and displays customer information. It doesn't matter how it gets the data, or what data tables it uses to get that data. If the user interface receives a request to query the customer information, it forwards the request to the user delegate (Customer Delegate) module. This module can find the corresponding module in the business layer to handle the corresponding data (constraint relationship). The customer object in the business layer aggregates all the information needed for the business request (in this case, the customer information). This module calls the customer DAO in the persistence layer to get the client information and calls the order DAO to get the ordering information. These modules execute SQL statements and then return the corresponding data to the business layer. When the customer object receives the data, it aggregates the data and passes it to customer delegate, which then passes the data to the customer screen before the user.

From a technical point of view, there are many ways to implement these modules. For example, in the Java platform, customer screen corresponds to the (JSF) Java Server Faces, which implements the customer delegate with the Bean component. Use a local spring bean or a remote EJB3 bean to implement the customer object in the business layer. The data access in the example above can be used with a simple POJP ' s (Plain old Java Objects), or you can use MyBatis, or you can query with JDBC or hibernate. On the Microsoft platform, customer screen can use the ASP module of the. NET Library to access C # modules in the business layer, using ADO to implement user and order data access modules.

Precautions

A layered architecture is a very reliable architectural pattern. It is suitable for most applications. If you're not sure what architecture to use in your project, the layered architecture is no better. Then, from an architectural point of view, there are many things to consider in choosing this pattern.

The first thing to note is the sewage pool anti-pattern (architecture sinkhole anti-pattern).
In this mode, the request flow simply passes through the hierarchy without leaving a little cloud, or leaving only a puff of green smoke. For example, the interface layer responds to a request to get data. The response layer passes this request to the business layer, and the business layer simply passes the request to the persistence layer, and the persistence layer makes a simple SQL query to the database to get the user's data. This data is returned by principle and will not be processed two times and returned to the interface.

Each hierarchical architecture is more or less likely to encounter this scenario. The key is how much such a request is. The 80-20 principle can help you determine whether the architecture is in anti-sewage mode. About 20% of the requests are just simple traversal, and 80% of the requests do business logic operations. However, if this ratio is reversed, most requests are simply going through the layer and not doing the logical operation. It would be nice to open up some architectural layers. However, because of the lack of hierarchical isolation, the project becomes unmanageable.

Pattern Analysis

The following table analyzes the various aspects of the layered architecture.

Overall flexibility

Rating: Low
Analysis: Overall flexibility is the ability to respond to changes in the environment. Although changes in layered patterns can be isolated, it is also time-consuming and laborious to make some changes in this architecture. The cumbersome and tight coupling between the layered patterns and the frequently occurring components is the cause of the reduced flexibility.

Easy to deploy

Rating: Low
Analysis: Depending on how you publish this pattern, the release program can be cumbersome, especially for large projects. A small change to a component may affect the release of the entire program (or most of the program). The publication must be published on a schedule, during non-working hours, or on weekends. So. Layered mode makes app publishing a bit less fluid and less flexible in publishing.

Testability

Rating: High
Analysis: Because the components are in their own hierarchy, you can simulate other layers, or remove layers directly, so layered mode is easy to test. Developers can simulate a presentation component individually and isolate and test business components. You can also simulate the business layer to test a presentation feature.

Performance

Rating: Low
Analysis: Although some layered architectures are performing well, the characteristics of this pattern make it impossible to deliver high performance. Because a business request crosses all the architectural layers, it does a lot of unnecessary work.

Elasticity of

Rating: Low
Analysis: Due to the trend of tight coupling in the development of this model, the scale is also relatively large, the program built with layered architecture is more difficult to expand. You can split the layers into separate physical modules or simply split the entire program into multiple nodes to extend the hierarchical architecture, but the overall relationship is too tight, so it's hard to scale.

Easy to be exploitative

Rating: Easy
Analysis: In the development difficulty above, the hierarchical structure obtains the relatively high score. Because this architecture is familiar to everyone, it is not difficult to achieve. Most companies are developing projects that are differentiated by layers, a model that is appropriate for most commercial project development. The link between the company's organizational structure and their software architecture is dubbed "Conway's Law." You can check this interesting link with Google.

Test Architect: Layered architecture of software architecture patterns 2