This is the 11th day of my participation in the August More text Challenge. For details, see: August More Text Challenge

Architectural design patterns

Applications that are not architected are often tightly coupled and difficult to maintain and extend. It is difficult to see the architectural characteristics of an application without understanding the inner workings of its components.

Questions about deployment and maintenance are difficult to answer:

  • What is the scale of the architecture?

  • How does the program perform?

  • Is the program easy to modify?

  • What is the deployment model of the application?

  • How did the program respond?

Software architecture patterns help you define the basic characteristics and behavior of a program. For example, some architectural patterns naturally make applications scalable. Some patterns make applications agile. Knowing these architectural characteristics, strengths, and weaknesses, you can take time to choose an architectural pattern based on your specific business needs and goals.

As an architect, you will always explain your architectural choices, especially when you choose a particular architectural pattern.

Software Architecture Principles

First Law of Software Architecture: Everything in software architecture is a tradeoff

Our definition of software architecture goes beyond the scope of structure to include principles, characteristics, etc. The scope of architecture is broader than simple structure, which is reflected in our second law of software architecture: Why is more Important than How

Layered Architecture

It is the most common architecture, also known as the N-Tier Architecture pattern. This is also the standard pattern that Java EE applications often adopt. Basically any programmer is familiar with it.

This architectural pattern is well suited to traditional IT communications and organizational structures and is a natural first architectural choice for most applications.

Model description

Components in a layered architecture are divided into layers, each of which represents a function of the application and each has its own specific role and function.

The layered architecture itself does not specify how many layers to divide into, most applications will be divided into presentation, business, persistence, and data layers.

Small applications sometimes combine the business layer and persistence layer together, while larger applications may have more layers, such as invoking external services.

One characteristic of hierarchical architecture is separation of concerns. Components in this layer are only responsible for the logic of this layer, and the division of components makes it easy for them to implement their own roles and responsibilities, as well as easier development, test management, and maintenance.

A key concept

Note that each layer is closed, which means that Request must go through each layer to reach the bottom layer.

Q: Why not allow the presentation layer to access the database layer directly? Wouldn’t that be faster?

This is another feature of layered architecture: Layers of Isolation.

The concept of layer isolation means that changes you make to one layer do not affect the others, which makes sense, but also means that the components of one layer have little or no knowledge of the implementation of the other layer.

For example, the business layer does not need to know exactly how your persistence layer is implemented.

The layered architecture also makes it easy to add new layers.

For example, if you want to reorganize some common services into a service layer, such as common image processing, remote account auditing, etc., you can add a service layer under the business layer. It does not affect the presentation layer, nor does it change the persistence layer code.

The above example creates a problem because each layer loses its closure and the business layer has to access the persistence layer through the service layer, which makes no sense. So sometimes you create an open layer. This means that the upper layer can bypass this layer and access the next layer directly.

Architectural considerations

The layered architecture is a reliable, generic architecture for many applications, and can be used as an initial architecture if you are not sure which architecture is right for your application. 1. Note the Architecture Sinkhole anti-pattern

The sump anti-pattern is where the request flow simply passes through several layers, each with little or no business logic being done. For example, in some JavaEE examples, the business logic layer simply calls the persistence layer’s interface and has no business logic of its own.

Each layer is more or less likely to encounter such a scenario, the key is to analyze what percentage of such requests are. The 80-20 rule can help you determine if you are encountering a cesspool anti-pattern. If your request exceeds 20%, you should consider making some layers open.

2. Consider that layered architecture can make your application huge

Even if your presentation layer and business layer can be published independently (e.g. the presentation layer uses the single-page technical framework AngularJS, EmberJS).

It does bring some potential problems, such as complex distribution patterns, reduced robustness, reliability, performance, and size.

conclusion

Combined with the above analysis, the overall analysis of layered architecture design pattern is as follows:

  • Overall flexibility: low

  • Release ease of use: low

  • Testability: high

  • Performance: low

  • Scale: low

  • Ease of development: high

– END –

Author: Architecture improvement road, ten years of research and development wind and rain road, dacang architect, CSDN blog expert, focus on architecture technology precipitation learning and sharing, career and cognitive upgrading, adhere to the sharing of grounding gas dry articles, look forward to growing with you. Follow and private message I reply “01”, send you a programmer growth advance gift package, welcome to hook up.

This article was published on the public account of the same name “The Way to Improve Architecture”, the original link: Layered Architecture of software Architecture patterns

Thanks for reading!