Application Layering: Principles, Alibaba Specification, and Optimized Practices

1. Background

When discussing application layering, many people think it is simple—just controller, service, and mapper layers. In practice, responsibilities are often not clearly separated; controllers sometimes contain more logic than services, and services become mere pass‑throughs. This leads to tangled code, poor reusability, and difficult maintenance.

Some developers follow existing code styles without questioning them, resulting in inconsistent habits across a team. One developer may place heavy business logic in controllers, while another prefers to call remote services from the service layer. Such divergent styles make future modifications confusing and error‑prone.

A good application layering should satisfy the following:

Facilitate maintenance and extension of code.

Be accepted by the whole team.

Define clear boundaries for each layer's responsibilities.

2. How to Perform Layering

2.1 Alibaba Specification

Alibaba's coding guidelines define the following layers:

Open Interface Layer: Wraps service methods as RPC interfaces, exposes HTTP interfaces, and handles gateway security, traffic control, etc.

Presentation Layer: Renders templates for various clients (Velocity, JS, JSP, mobile, etc.).

Web Layer: Performs access control, basic parameter validation, and simple non‑reusable business processing.

Service Layer: Contains concrete business logic.

Manager Layer: General business processing, such as third‑party platform wrappers, common capabilities (caching, middleware handling), and coordination of multiple DAOs.

DAO Layer: Data access, interacting with MySQL, Oracle, HBase, etc.

Although Alibaba's layering is clear, many developers still confuse Service and Manager layers, leading to projects that omit the Manager layer entirely. The following sections describe how to implement layering in real projects.

2.2 Optimized Layering

Based on our development experience, we propose an ideal model. Note that our RPC framework uses Thrift, which adds an extra layer similar to a controller.

1. Top‑most Controller/TService: Handles lightweight business logic, parameter validation, and exception handling. It should remain thin so that the interface can be easily swapped.

2. Service: Implements business logic with low reusability. Each controller method should correspond to a distinct service method; business orchestration should not reside in the controller.

If business orchestration stays in the controller, adding a new entry point (e.g., Thrift) would require duplicating the orchestration code, leading to redundant work as shown below:

To avoid this duplication, the orchestration logic should be placed in the service layer:

3. Manager: Reusable logic such as caching, messaging, or composite operations (e.g., multi‑table joins). HTTP or RPC managers may also perform data transformation.

4. DAO: Database access layer, responsible for mapping tables to Java objects. Only the corresponding service should access its DAO; other services must go through the service layer.

3. Domain Model Transformation Across Layers

Alibaba's specification lists several domain models:

DO (Data Object): Directly maps to database tables, transferred via DAO.

DTO (Data Transfer Object): Used by Service or Manager to transfer data outward.

BO (Business Object): Encapsulates business logic output from the Service layer.

AO (Application Object): An intermediate reusable model between Web and Service layers, closely tied to the presentation layer.

VO (View Object): Object passed to the view/template engine.

Query: Query object for data retrieval; avoid using Map for more than two parameters.

Strictly separating models for each layer can cause excessive conversions—an object may be transformed 3‑4 times during a single request, and the same occurs on the way back, leading to unnecessary overhead.

We recommend a compromise:

Allow Service/Manager layers to operate on domain models directly, handling business processing and data assembly.

Prohibit Controllers/TService from passing their domain models directly to the DAO layer.

Similarly, DAO data should not be passed directly to Controllers/TService.

4. Summary

In summary, proper application layering is crucial for code standards, reusability, and clear responsibility boundaries.

While layering practices can be subjective and vary among team members, the key is to ensure logical clarity and ease of maintenance.

If your team has a better layering approach or finds any errors in the above description, please leave a comment.

Additionally, the author has completed two column articles
Mybatis Advanced
and
Spring Boot Advanced
, which have been compiled into a book. Reply with the keywords
Mybatis 进阶
or
Spring Boot 进阶
to the public account to obtain it for free.

Good article, I'm watching ❤️