1. Why stratification

  • High cohesion: Layered design simplifies system design, allowing different layers to focus on one module

  • Low coupling: Layers interact with each other through interfaces or apis, without dependent parties knowing the details of dependent parties

  • Reuse: High reuse can be achieved after layering

  • Scalability: Layered architecture makes it easier to scale horizontally

If the system is not layered, we can only scale for the whole system as business size increases or traffic increases. After the layer can be very convenient to pull out some modules, independent into a system.

2. Traditional MVC architecture

Advantages: Focus on front and rear end separation

Disadvantages: the model layer layer is too coarse, integrating all functions such as data processing and business processing. The core complex business logic is put into the model layer, resulting in chaos in the model layer

Application scenario: Back-end services with simple service logic, such as interfaces for adding, deleting, modifying, and querying databases

3. Back-end three-tier architecture

Definition:

  1. Presentation layer: Controller
  2. Logical layer: Service
  3. Data access layer: DAO

Advantages: Logic and data layer separation

Disadvantages: The model layer is relatively coarse, and the complex business logic of the core is put into the model layer, leading to the chaos of the model layer

Application scenario: Back-end services with simple service logic, such as interfaces for adding, deleting, modifying, and querying databases

4. Alibaba layered architecture

Architecture source: Refer to the “Alibaba Java development Manual V1.4.0 (detailed version)” issued by Ali, the original three-tier architecture is refined

Features: Added Manager general business processing layer.

This layer has two functions. First, it can sink some common capabilities of the original Service layer into this layer, such as interaction strategy with cache and storage, middleware access. Second, it can also encapsulate calls to third-party interfaces in this layer, such as calling payment services, calling audit services and other RPC interfaces.

Advantages: Compared with the three-layer approach, a common processing layer is added to connect to the external platform. Upstream and downstream docking division is relatively clear

Disadvantages: No division of the core business logic layer

Application Scenario: Common services with uncomplicated service logic

5. DDD layered architecture

(1) Features

  1. Data, caching, and so on are considered base layers and can be called by all layers
  2. The domain layer is separated from the core business logic processing, and the external dependencies of the domain layer are all called through the interface to ensure 100% single test coverage of the domain layer
  3. The application layer aggregates the capabilities of multiple domain layers and only performs function combination and forwarding, not specific business logic

Advantages: Compared with the three-tier approach, it pays more attention to domain services, namely the division and convergence of business core logic

Disadvantages: Complex layering is not necessary if the business logic is simple

Application Scenario: Complex services

(2) Comparison with traditional three-tier architecture

The DDD four-tier architecture is also based on the traditional three-tier architecture. The differences are as follows:

  1. Concerns vary: the three-tier architecture focuses on the order in which requests are invoked; The DDD architecture focuses on domain services.
  2. 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.
  3. 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.

Clean architecture and hexagonal architecture

Clean architecture and hexagonal architecture are both ways of DDD architecture, but from different perspectives.

(1) Clean architecture

Features: The layers of clean architecture are like onion slices, reflecting the idea of layered design

The most important principle of clean architecture is the dependency principle, which defines the dependencies at each level, the lower the dependencies, the higher the code level, and the more core capabilities. The outer circle code depends on pointing only to the inner circle, and the inner circle doesn’t need to know anything about the outer circle.

(2) Hexagonal architecture

Hexagonal architecture is also known as “port adapter architecture”. Tracing the origins of microservices architectures, it is common to refer to hexagonal architectures.

The core idea of the hexagonal architecture is that applications interact with the outside world through ports. I think this is the main reason for the popularity of API gateways in microservices architecture.

In other words, in the hexagonal architecture shown below, the core business logic (application and domain model) in the red circle is completely isolated from external resources (APP, Web application, database resources, etc.) and interacts only with adapters. It solves the interleaving problem of business logic and user interface code, and achieves the separation of front and back ends. The dependencies of the layers of a hexagonal architecture are as external as they are in a clean architecture.

7, a summary

This paper summarizes the traditional MVC architecture, back-end three-tier architecture, Ali layered architecture, DDD architecture, clean architecture and hexagonal architecture based on DDD architecture. It’s getting more and more complex from front to back, and other things are getting more and more complex in software engineering, and architectural patterns are getting more and more complex. Software architecture domain without a recruit fresh day eating achievement method, different business scenarios according to the different architecture, and with the development of the business, continuously adjust the structure to adapt to the development of the business, to become (architecture, components, refactoring, etc.) should be the same (business development, user experience, stability, etc.) is a qualified software engineers should be the pursuit of the realm.

The original link

Author public id: Java development