preface

As long as engaged in software development work, system architecture is a necessary knowledge. Some friends said that they might say, I am just a brick moving, how can I get access to architecture knowledge? In fact, in addition to the architect (that is, the architect), as ordinary developers are always practicing the theory of system architecture. After all, no matter how good an architecture is, it takes a coder to implement it. It’s just that when you don’t have a systematic understanding of software architecture, you may not know it.

This article will take you through a systematic understanding of software architecture layering, after learning, you will understand why systems are layered. At the same time, it can accurately see what kind of layered architecture is used in the current system.

No architectural layering, okay?

First of all, let’s think about the question, is it ok if a system doesn’t have a hierarchical architecture? This question is like asking, is it ok not to use design patterns in your code? The answer, of course, is yes. Without architectural layering, however, there is a great deal of unknown risk, or the very entropic nature of the code.

As a start-up software, there may be no business logic and no number of users, but the main goal of the software is to quickly go online and practice the business model. At this point, you can forget about layering. However, with the complexity of business logic, the increase of business modules, there will be complex dependence between each other, and then there will be unclear logic, poor readability, difficult maintenance, change a whole body and other problems.

What is architectural layering?

Layered architecture is to divide software modules into multiple layers according to the way of horizontal segmentation. A system is composed of multiple layers, and each layer is composed of multiple modules. At the same time, each layer has its own independent responsibilities, and multiple layers collaborate to provide complete functions. For example, the MVC architecture, which we often talk about, is a very typical and very basic layered approach.

In fact, the essence of layered design is to simplify complex problems, make each layer of code perform its own duties based on the principle of single responsibility, and realize the interaction between objects of related layers based on the design idea of “high cohesion, low coupling”. Thus, code maintainability and extensibility are improved.

After the system architecture is layered, the following goals are often needed:

  • High cohesion: Layered design simplifies system design and allows different layers to focus on one module;
  • Low coupling: Layer to layer interaction through interfaces or apis, dependent parties do not know the details of dependent parties;
  • Reuse: the reuse of code or functions can be achieved after layering;
  • Extensibility: A layered architecture makes it easier for code to scale horizontally

OSI reference model for communications

OSI reference model and TCP/IP reference model are the most typical hierarchical architecture designs in the field of computer. About this model, we read an article only three times, Never forget network layering! This has been described in detail in an article. Let’s look directly at the relevant model diagram:

For the three layering modes mentioned above, imagine that without layering, when a business or protocol needs to be changed, we can only modify or extend the entire system. After stratification, it is very convenient to pull out modules with different functions and modify the corresponding modules. Different layers can also be reused, just make sure they are handled according to the protocol of that layer.

Software systems are layered as a whole

Taking Java software applications as an example, the entire software system can also be layered, for example, into the deployed hardware environment, operating system, required middleware, business-bearing applications, and software access layer. You can see the following figure for an overall understanding:

Corresponding positions are also created for the above layers, such as operation and maintenance engineer, middleware engineer, product manager, development engineer, test engineer and so on. In our practice, the most contact, the most used layer is the application software layer, followed by the middleware layer.

Let’s take a look at some common layering methods for the application layer.

Classic three-tier architecture

The 3-tier application usually divides the entire business application into the presentation layer (UI), business logic layer (BLL), and data access layer (DAL).

The Presentation layer (UI), generally speaking, is the interface presented to the user. The Corresponding Web layer in the project contains servlets and controllers, etc.

Business Logic layer (BLL) : Also known as the domain layer, responsible for the processing of system business logic, corresponding to the project Service and ServiceImpl, etc.

Data Access Layer (DAL) : the transactions of this layer directly operate the database, and add, delete, modify, update and search data, corresponding to Dao in the project.

In the era when this layered Architecture was proposed, most systems were often simple, essentially Monolithic Architecture database management systems. This layered architecture is an evolution of the client-server architecture, effectively isolating the business logic from the data access logic, allowing the two different concerns to evolve relatively freely and independently.

In the open source technical framework, the representative works of presentation layer implementation are Struts1/2 and Spring MVC, the representative works of business layer implementation are Spring, and the representative works of persistence layer implementation are Hibernate and Mybatis.

MVC

The full name of MVC is Model View Controller, which is the abbreviation of Model, View and Controller. It is a Model of software design. It organizes code by separating business logic, data and interface display, and gathers business logic into one component. There is no need to rewrite business logic while improving and customizing interfaces and user interactions. MVC has been uniquely developed to map traditional input, processing, and output functions in a logical graphical user interface structure.

The standard MVC interaction model is shown below:

View: provides a user interface for direct interaction with users.

Model: a module that carries data and calculates user submitted requests. It is divided into two categories, one is called data bearer beans, one is called business processing beans. Data-hosted beans are entity classes that specifically host business data, such as Student, User, and so on. A business processing Bean is a Service or Dao object that handles user-submitted requests.

Controller: a Controller that forwards user requests to the corresponding Model for processing and processes the results of the Model to provide a response to the user.

Can be seen in the figure, the standard of the MVC model can take the initiative to push data to the view to update (observer design pattern, register the view on the model, when the model is updated automatically update the view), but in the Web development model cannot be active to view (can’t take the initiative to update the user interface), because in the Web development is request – response model.

Web MVC standard architecture, as shown below:

In the Web MVC pattern, the model cannot actively push data to the view, and if the user wants to update the view, he needs to send another request (the request-response model). MVC is used to decouple the Responsibilities of the Web (UI) layer.

The difference and connection between three-tier architecture and MVC

MVC is strictly speaking the UI layer in the three-layer architecture, that is to say, MVC divides the UI layer in the three-layer architecture again into controller, view and entity. The controller completes the page logic and communicates with the interface layer through entity, while the C layer directly communicates with the BLL in the third layer.

Three-tier architecture and MVC can coexist. Three-tier architecture is segmented based on business logic, whereas MVC is segmented based on page. MVC is a Presentation Pattern, and three-tier Architecture is a typical Architecture Pattern.

The hierarchical pattern of the three-tier architecture is typical of the relationship between the top and the bottom, with the top dependent on the bottom. However, MVC as a presentation pattern does not have a top-down relationship, but a cooperative relationship. Even if MVC is considered an architectural pattern, it is not a hierarchical pattern. MVC and three-tier architecture are hardly comparable and are technologies applied to different domains.

Ali four-tier architecture

The three-tier architecture is relatively easy to implement, and many of you may think that project layering is the way it should be. As a result, you often end up with a lot of business logic stacked in the Service layer. In “Alibaba Java Development Manual”, the original three-tier architecture is further refined and Manager general business processing layer is added.

The Manager layer can sink some of the common capabilities of the original Service layer, such as the interaction strategy with cache and storage, middleware access; It can also encapsulate calls to third-party interfaces, such as payment services, auditing services, and RPC interfaces.

Generic business processing layer, which has the following characteristics:

  • For the layer encapsulated by the third party platform, the preprocessing returns the result and transforms the abnormal information.
  • Degradation of Service layer common capabilities, such as caching schemes, middleware common processing.
  • Interacts with the DAO layer to reuse multiple DAOs in combination.

The functions of its layers are as follows:

  • Terminal display layer: the layer where the end templates render and perform display. Currently, Velocity rendering, JS rendering, JSP rendering, mobile terminal display, etc.
  • Open interface layer: encapsulates Service layer methods as open interfaces, and implements gateway security control and flow control.
  • Web layer: it mainly forwards access control, verifies all kinds of basic parameters, or simply deals with services that do not reuse.
  • Service layer: business logic layer.
  • Manager layer: Common business processing layer.
  • DAO layer: Data access layer, which interacts with MySQL, Oracle, and HBase at the bottom.
  • External interface or third party platform: including RPC open interface of other departments, base platform, HTTP interface of other companies.

Systems engineering structure

After learning the above layered architecture, let’s look at the table of comparison relation for layered software system:

The above hierarchical definitions are for reference only. In the above table, there are also more external interface layer and access layer.

External interface layer: All external interfaces are placed in this layer and cannot contain any business logic, only data object conversion and exception encapsulation.

Access layer: All external system dependencies are placed in this layer, with the advantage that if the external system interface is changed, it only needs to be changed in one place.

DDD layered architecture

DDD is a methodology for software architecture design that deals with highly complex domains. It tries to separate the complexity of technical implementation and build domain models around business concepts.

The DDD layered architecture treats data, caching, and so on as basic layers that can be called by all layers; Separated from the domain layer, responsible for core business logic processing, domain layer calls external dependencies all through the interface, to ensure 100% single test coverage of the domain layer; The application layer aggregates the capabilities of multiple domain layers and only performs function combination and forwarding, not specific business logic.

We are only going to give a brief introduction to DDD layered architecture. We are not going to expand DDD concepts too much. Take a look at the DDD hierarchy architecture diagram:

The functions of the corresponding layer are described as follows:

Interfaces: This layer contains everything that interacts with other systems, such as Web servers and RESTful Interfaces. The interface layer deals with the interpretation, verification, encoding and decoding and serialization of incoming data. At the same time, special Dtos (Data conversion objects) can be introduced to assist data conversion.

Application layer: This layer is responsible for driving applications to complete workflows. A thin layer that coordinates multiple domain objects (entities, aggregate roots, domain services) to implement service orchestration and compose completion workflows should not normally contain specific business logic. This layer covers: other microservice RPC calls, microservice choreography and composition, distributed transaction implementation, message-driven event drivers, logging, and so on.

Domain layer: this layer is the core of the software, including the concrete implementation of business logic, including entities, value objects, aggregation, Domain services, warehousing interfaces and other Domain objects. Usually, this layer should be equipped with ICONS to tell how the software works.

Infrastructure: Includes common technologies and Infrastructure services such as gateways, caching, database storage, message-oriented middleware, monitoring, application services, and so on. The base layer supports the other three layers in different ways to facilitate communication between the layers. Configuration files, database Schema Schema definitions, and warehouse interface implementations are all part of the infrastructure;

DDD Layered architecture Comparison of traditional three-tier architectures

The DDD four-tier architecture is also based on the traditional three-tier architecture.

The DDD four-tier architecture has the following differences from the traditional three-tier architecture:

  • Concerns vary: the three-tier architecture focuses on the order in which requests are invoked; The DDD architecture focuses on domain services.
  • The horizontal division is different: three-tier architecture mainly focuses on vertical division, and there is no agreement on horizontal division; The DDD architecture focuses more on the vertical, that is, how multiple domain layers are divided and interact.
  • The positioning of resources is different: the three-tier architecture puts all dependent data in the data access layer; The DDD architecture only puts domain-related data in Repository, while other services, such as API-layer caches and files, are treated as basic services.

There are two forms of DDD architecture hierarchy: clean architecture and hexagonal architecture. Here, we will not expand the DDD architecture. Interested friends can find relevant information to learn by themselves.

summary

This article explains common architectural layering on the market. The purpose of the layered architecture is to reduce the complexity of the system through separation of concerns, while satisfying single responsibility, high cohesion, low coupling, improved reusability, and reduced maintenance costs. However, layered architecture also has certain disadvantages, such as high development cost, slightly lower performance, and low scalability. In practice, you can choose the appropriate hierarchical architecture based on your needs.

About the blogger: Author of the technology book SpringBoot Inside Technology, loves to delve into technology and writes technical articles.

Public account: “program new vision”, the blogger’s public account, welcome to follow ~

Technical exchange: Please contact the weibo user at Zhuan2quan