The layered monolithic architecture style is the application of layered thinking in the monolithic architecture, which focuses on the layering of responsibilities from a technical perspective. At the same time, based on the different change rates of different layers, the propagation of changes in the system can be controlled to a certain extent, which helps to improve the stability of the system. However, this separation of concerns from a technical perspective rather than a business perspective leads to a gap between the problem domain and engineering implementation, and this separation will lead to an increase in the cognitive complexity of the system.

Author: Ni Xinming

1.1 Four-tier monolithic architectural style

The classic four-layer monomer layered architecture is shown in the figure below. The application is logically divided into presentation layer, business layer, persistence layer and data storage layer. The responsibilities of each layer are as follows:

•
presentation layer:Responsible for displaying information to end users and accepting user input to trigger the business logic of the system. Users can be people who use the system or other software systems.

•
Business Layer: Focus on the implementation of system business logic

•
persistence layer: responsible for data access

•
data storage layer: the underlying data storage facility





This layered monolithic architecture may be the earliest and most familiar application architectural style for most developers. Its characteristics are:

•
The dependencies between layers are directly dependent from top to bottom, each layer is closed, and the requested data flows from top to bottom, and must be strictly passed through each layer, and penetration calls cannot be made.

•
Segregation of concerns:The focus of the system is distributed vertically through layering. Each layer only focuses on the responsibilities within its own layer boundary, and the responsibilities between layers are independent of each other and there is no intersection. For example, the business layer is responsible for processing the core business logic of the system, while the persistence layer focuses on accessing data.

In addition to the dimension of separation of concerns, layering is also “VarietyThe change rate of each layer is different, and it increases layer by layer from the lower layer to the upper layer. The change rate of the presentation layer is the fastest, and the change rate of the data storage layer is the lowest. Through strict layer dependency constraints, the impact of lower layer changes on the upper layer is minimized. .The context of this feature is that layers depend on abstraction rather than concreteness. When the implementation changes but the interface contract remains unchanged, the scope of change is limited to the current layer. However, if it is a change in the interface contract, it may Directly affects the upstream dependency layer.

This layered architectural style has clear advantages:

•
The hierarchical model is relatively simple,Low cost to understand and implement

•
Open personnel have high acceptance and familiarity,Low cognitive and learning costs

1.2 Five-layer monolithic architectural style

The problems faced by the four-tier architecture are:

•
Data efficiency issues between layers: Due to the dependency constraints of inter-layer call relationships, data transfer between layers requires additional costs

•
Business Layer Service CapabilitiesReusability: There is a demand for shared services between components or modules in the same position in the business layer

From the perspective of reusability, in the five-layer architecture shown below,Solve the reuse problem by introducing the middle layer. Deposit shared services from the business layer to the general service layer to improve reusability. Its characteristics are:

•
Introduce a general service layer to provide general services and improve reusability

•
The general service layer is an open layer that allows call link penetration, and the business layer can directly access the lower persistence layer as needed





Compared with the four-tier architecture, the main advantage of the five-tier hierarchical architecture is that the introduction of the middle layer solves the problem of system reusability to a certain extent. But from a reverse perspective, it is the introduction of the middle layer that leads to the following problems:

•
Introduce the middle layerReduced data transmission efficiency and increased development and implementation costs

•
have causedRisk of increased systemic chaos: Due to the openness of the general service layer, the business layer can penetrate the call. However, this kind of scene that needs to be penetrated cannot form a unified judgment principle, and it often depends on the personal experience of the implementer to make a trade-off. The same business scenario implemented by different developers may have different judgment results (in the four-tier architecture This problem will also exist if you let go of the inter-layer calling constraints). As business requirements iterate, system dependencies will increase day by day, eventually forming complex call relationships, which will also lead to an increase in system complexity and increase the cognitive cost of team members.





Of course, it is precisely because of its high acceptance that people have misunderstood stratification, thinking that stratification is an inevitable “default option”, thus ignoring the essence of stratification. What problem does stratification solve?

Hierarchy is essentially a way to deal with complexity: abstract complexity at different levels, and segregate responsibilities through hierarchies, thereby reducing cognitive costs. At the same time, through the “barrier” formed by layering, the spread of changes between systems is controlled to improve system stability.

Whether it is a four-tier architecture or a five-tier architecture, it is the practice of layered thinking in the single application architecture style. The inherent problems of this layered model are mainly reflected in the following aspects:

•
Effect of Layering on System Complexity and Efficiency

•
Can changes really be completely isolated?

•
Isolation of problem domain and solution

2.1 Influence of Layering on System Complexity and Efficiency

As mentioned above, each layer in a layered architecture changes at a different rate. The higher it changes, the faster it changes, and the lower its stability; the lower it changes, the slower it changes, and its higher its stability. For example, the user display logic of the presentation layer may change frequently, and the display data and forms may be different for different scenarios.





If there are more levels of division and stricter inter-layer dependencies, the call links and dependencies of the system will be clearer. However, the longer the link between the request and the response, the extra cost for inter-layer data conversion. Even if various data conversion tools are introduced, such as MapStruct, the implementation will still feel very cumbersome and repetitive.

If there are more layers, the dependencies between layers are loose, and cross-layer calls are allowed (the calling of the persistence layer from the presentation layer as shown below is just a hint), the cost of frequent data conversion can be reduced to a certain extent. but:

•
One: How to determine whether to call across layers is difficult to form a unified and strict judgment standard, and only coarse-grained division can be performed. Therefore, there will be different judgment results in the implementation process, and the calling relationship of the system will become more and more complicated as the code size increases. Of course, the team can strengthen the granularity of code review, and each review discusses, judges and reaches a consensus based on whether to penetrate the call. But the practical experience is that due to the human factor, strict code review does not guarantee the consistency of decision-making.

•
Second: If cross-layer calls are allowed, it means the penetration of the “model”, and the lower-level model will be directly exposed to the upper layer, which conflicts with the cohesion of components and the encapsulation of the model we are pursuing

Note: The dependency constraint between layers is an architectural decision, which can be guaranteed through an automated unit testing mechanism. For details, refer to

” Based on ArchUnit guard system architecture “

” Lightweight architecture decision recording mechanism – ADR“

2.2 Isolation of changes

We have a common, “preconceived” perception of layering, the ability to insulate change. The first example that comes to mind, for example, if the underlying database changes, or the ORM framework changes, then we only need to modify the implementation of the DAO layer without changing the upper-layer business layer code.

•
Are you actually going to replace the database? Would you really replace the ORM framework? It is possible, but the probability is very low, and this scenario will not happen to most systems.

•
Can it really be isolated if a replacement occurs? If your layers do not depend on abstraction, but on concrete, then isolation is out of the question.

•
Even if layers rely on abstractions, is change really isolated? The direct result of the change in implementation is that the relying party needs to refer to the new implementation, and this change will also affect the upper layer.It’s just that this change may be handed over to the IOC container

But is this all there is to change isolation??

•
What if a new field needs to be added to the presentation layer, but not in the current database model?

•
If a new field needs to be added in the database, but the presentation layer and business logic layer don’t care?

•
in the case of……

Therefore, there are many reasons for system changes, different scenarios, different business demands, and different levels of isolation from changes:

Layering can control the propagation of changes in the system. Due to the diversity of change scenarios, layering cannot completely isolate changes.





2.3 Separation of problem domain and solution

Rethink one of the characteristics of the layered monolithic architecture mentioned above: focus isolation, presentation layer, business layer, data access layer, storage layer and other layers focus on their own responsibilities. What is the nature of this focus?

Isolation from a technical perspective! ! !

Each layer isolates technical concerns from a technical perspective rather than a business domain perspective. The technical perspective is friendly to R&D. As a developer, you can naturally understand and accept this unified language of technical dimensions: the DAO layer is only responsible for processing data-related logic, the service of the Controller layer is related to the Restful API, and the RPC layer only deals with external systems. cross-process calls and so on.

As for very core business concepts, such as taking orders as an example, it is necessary to answer such a question under the single layered architecture:Where is the “order component”?

In the classic layered monolithic architecture style, a typical implementation is shown in the following figure:

•
OrderConroller: Rest interface for system access under the Spring technology stack

•
OrderService/OrderServiceImpl: The core business logic of the order implements services, such as placing an order, canceling an order, etc.

•
OrderDAO/OrdeDAOImpl: access to order data





order componentdoes not exist as a single, cohesive thingits component elements OrderService and its dependent OrderDAO are scattered in different layers. Therefore, the order component in this mode is justlogical, conceptualThe presence. As the core abstraction of the business domain, the order component has no real, intuitive, and cohesive reflection in the code implementation. We look for “order components” in the engineering codebase:

•
First of all, the first thing you see at the top level of the project is the Module (Maven Module) from the technical perspective: web, service, dao

•
Then, you need to navigate through the layers to see the full picture

With the support of the IDE, this kind of navigation is not very complicated. But the root of the problem is:Increased cognitive cost.

Let’s get to know the system,It is natural to start from the business domain rather than the technical domain, and the monomer layering is precisely from the technical domain rather than the business domain. This difference leads to the separation between the business domain and the implementation, and increases the cognitive cost of the system.

Realization needs to reflect abstraction. Component thinking is essentially a kind of modular thinking. Through cohesion and encapsulation, the problem space is split into subspaces and divided and conquered. Externally provide component capabilities through interfaces, shielding internal complexity. The size and granularity of the interface contract need to be weighed. The smaller the granularity, the more focused the capability provision, the lower the cost of understanding and access, but the lower the versatility. The greater the granularity of the interface contract, the stronger the versatility, but the higher the complexity of understanding and access.





Applying component thinking to the single-layer architecture leads to the modular single-architecture style.Application architecture is organized modularly by problem domain, rather than split based on technical concerns. Components follow the principle of cohesion, which contains all elements and interaction relationships required to realize component capabilities. Components interact through a unified interface contract with appropriate granularity, and do not directly depend on the internal capabilities or models of the components. At the same time, a well-organized modular monolithic application architecture is also an important guarantee for microservice splitting. How can you talk about reasonable microservice splitting if you can’t carry out an elegant modular organization in a monolithic architecture?



Monolithic layered architecture style is the application of layered thinking in monolithic architecture, which focuses on the layering of responsibilities from a technical perspective. At the same time, based on the different change rates of different layers, the propagation of changes in the system can be controlled to a certain extent, which helps to improve the stability of the system. However, this separation of concerns from a technical perspective rather than a business perspective leads to a gap between the problem domain and engineering implementation, and this separation will lead to an increase in the cognitive complexity of the system. Applying component thinking to the hierarchical architecture of the monomer, the layering of the modular monomer technology perspective is pulled back to the modularization of the business domain perspective, which reduces the isolation between business and engineering implementation to a certain extent. Good modularity is an important cornerstone for a monomer to move towards microservices. If a system with poor modular design will not only increase the cost of microservice splitting, but more importantly, it will increase the probability and risk of forming a distributed monomer .