Star/fork: Java-interview-Tutorial github.com/Wasabi1234/…
General start-up software, in order to quickly go online, almost no consideration for layering. However, as the business becomes more and more complex, it will lead to complicated logic, module interdependence, poor code scalability and other problems.
Architectural layering is imperative.
What is architectural layering?
In the common design method in software engineering, the overall system is divided into N levels, each level has independent responsibilities, and multiple levels collaborate to provide complete functions.
Starting JavaWeb requires an MVC architecture. Another common way of layering is to divide the overall architecture into groups
- Presentation Layer (Web)
The layer closest to the user displays data results and receives user instructions.
- Logical Layer (Service)
Concrete implementation of complex business;
- Data Access Layer (Dao)
Primarily dealing with the interaction between and storage.
This isolates concerns and lets different layers focus on doing different things. Other layered examples, such as OSI network layer 7 model, TCP/IP protocol network layer 4 model.
What are the benefits of layering?
To simplify the design
Each division is full – time, rather than living a full – time.
High reuse
For example, in the design of a system, it is found that a layer has universality, it can be extracted and used independently in the design of other systems.
Horizontal scaling
It makes it easier to scale horizontally. If the system is not layered, we need to scale for the overall system as traffic increases. However, if we layer the system according to the three-tier architecture mentioned above, we can make detailed extensions for specific problems.
For example, if the business logic contains complex calculations, causing THE CPU to become a performance bottleneck, then the logical layer can be isolated and deployed independently, and then only the logical layer is extended, which is much less costly than the overall system expansion.
What is the relationship between architectural layering and high concurrency design? We know that scale-out is one of the ideas of high-concurrency design, and if architecture is layered to facilitate scale-out, then high-concurrency systems must be layered.
3 How to Layered architecture?
The key is to clarify the hierarchical boundaries. Wouldn’t it be easy to define boundaries with a three-tier architecture? Yes, when the business logic is simple, the boundaries between layers are really clear and you know where to write code when developing new features. But as business logic becomes more complex, boundaries blur.
3.1 case
Any system has a User module, such as an interface to return User information, which calls the GetUser method at the logical layer, which in turn interacts with the User DB to retrieve data, as shown on the left in the figure below.
At this time, the product puts forward a requirement that when displaying the user information in the APP, if the user does not exist, it will automatically create a user for the user. At the same time, do an HTML5 page to preserve the logic before, that is, you don’t need to create users. At this point, the boundaries of the logical layer become unclear, and the presentation layer also takes over part of the business logic (retrieving users and creating user interface associations).
3.2 Mainstream stratified responsibilities
The simplicity of MVC architecture makes too many people think that the project engineering structure should be taken for granted. Then, a lot of business logic is piled up randomly in service. Objects are only for the purpose of data transmission, and it is common to write process-oriented programs in object-oriented language. According to the idea of domain-driven design, it is most important to have a domain model layer. Of course, the scheme of manage layer is also a way of thinking, but IN my opinion, this way is not enough. Only with clear business model and reasonable hierarchical structure, can we better realize the role of cash layering.
Terminal display layer
Each end template renders and executes the layers displayed. Currently, I mainly focus on Velocity/ Framemaker rendering, JS rendering, mobile terminal display, etc
Open interface layer
The Service layer method is encapsulated as an open interface, and the gateway security control and flow control are carried out at the same time
The Web tier
It mainly forwards access control, verifies all kinds of basic parameters, or simply deals with services that do not reuse
The Service layer
Business logic layer. Call the Manager layer and the DAO layer to process business, that is, simple business can call the DAO directly without extracting the Manager. Business class validation is placed in the Service layer, and general parameter validation is placed in the Web layer, which can be generalized.
Manager layer (Common Business processing layer)
It is a simple analogy to the domain layer in DDD.
- Some of the common capabilities of the original Service layer can be sunk into this layer, such as interaction policies with caching and storage, and access to middleware. Business logic is placed in Manager, Service to orchestrate the manager’s atomic services.
- This layer also encapsulates calls to third-party interfaces, such as payment services, auditing services, and so on
Compared with MVC, this layered architecture mainly adds the Manager layer, which has a relationship with the Service layer: The Manager layer provides atomic Service interfaces, and the Service layer is responsible for arranging atomic interfaces according to business logic.
- Business logic is your product logic, like what you do to create users.
- Atomic services at the Manager layer refer to services that implement a single function.
- Transactions should be in the Service layer
DAO Layer (Data Persistence Layer)
Data access layer: Interacts with the underlying MySQL, Oracle, and HBase. Caches can be placed in the storage tier.
External interfaces or third-party platforms
Including other department RPC open interface, base platform, other company HTTP interface
For example, the Manager layer provides interfaces for creating users and getting user information, and the Service layer is responsible for assembling the two interfaces. This unifies the business logic that was previously scattered in the presentation layer into the Service layer, with clear boundaries at each layer.
For example, to make an interface, you can put the implementation in the Service layer. The internal company call logic can then be placed in the Web layer. When the company wants to open up this interface, it can directly abstract a new layer (a new service), the open platform layer! This has the advantage of isolating the division’s use from third party use. For example, when providing services, traffic limiting is performed on the open platform layer to ensure its own interface performance.
Traditional companies are often layered, such as insurance and finance. The Service and DAO are deployed in a tight network zone, and the Controller layer is deployed in a loose network zone to provide external services. A buffer is added on the network to ensure the security of the service. It can also be called through the one-way network specification hierarchy, and the Controller can call the service layer, which cannot call the Web layer. If the data access layer is deployed separately, such as splitting into separate RPC services, of course this splitting is more granular. A controller is an external facade that invokes a separate service layer
- It can reduce the cost for later service operation and maintenance
- It can improve the reuse degree of the data access layer (the data access layer provides API externally, and the applications of other layers interact with the database through API), and third, it can mask the details of the implementation of each database.
3.3 Inter-layer dependency
Data flows can only be between adjacent layers. Taking the three-tier architecture as an example, data must be transferred from the presentation layer to the logical layer for business logic processing, and then to the data access layer and DB interaction. But if the business logic is simple, can you go directly from the presentation layer to the data access layer, or even read DB directly? Functionally yes, but in the long run architectural design, this can cause hierarchy confusion, such as the need to change layers once the DB address changes, which loses the value of hierarchy, and maintenance or refactoring is a disaster.
4 Defects of architecture layering
4.1 Increase code complexity
It was possible to query DB directly after receiving the request to get the result, but it had to be designed in the middle layer, each layer simply doing data transfer. Sometimes adding a small requirement, which may require changing all layers of code, increases development costs, debugging complexity, and communication costs with other module owners.
4.2 Performance Loss
If each layer is deployed independently and interacts with each other over a network, the multi-layer architecture will inevitably suffer in terms of performance.
Should we choose architectural layering? For sure.
You have to know that any solution architecture has advantages and disadvantages, the world is not complete, let alone our architecture? It is true that layered architecture will increase system complexity and may have performance loss, but compared to the benefits it can bring to us, these are acceptable, or can be solved by other solutions. When we make decisions, we must not make a generalization and give up eating for fear of choking.
5 concludes
Layered architecture is the external embodiment of software design thought and is a way of implementation. Some software design principles are embodied in the layered architecture.
For example, the single responsibility principle stipulates that each class has only a single function, which can be extended to mean that each layer has a single responsibility and the boundary between layers is clear. The original meaning of Demeter’s law is that an object should know as little as possible about other objects. In hierarchical architecture, data interaction cannot be carried out across layers, but only between adjacent layers.
The open closed principle requires software to be open for extension and closed for modification. In fact, its meaning is to separate the abstraction layer and the implementation layer. The abstraction layer is the summary of the common characteristics of the implementation layer, which can not be modified, but the concrete implementation can be infinitely extended and replaced at will.
reference
- Alibaba Java Development Manual