Mastering Application Layering: Best Practices for Clean Backend Architecture

Background

Many developers assume application layering is simple—just controller, service, and mapper—but responsibilities often blur, leading to tangled code, poor reuse, and maintenance headaches.

A good layering approach should be easy to maintain and extend, accepted by the whole team, and have clear responsibility boundaries.

How to Layer

Key requirements for a solid layer structure:

Facilitate future maintenance and extension.

Be embraced by the entire team.

Define clear boundaries for each layer.

Alibaba Specification

Alibaba's coding guidelines define the following layers:

Open Interface Layer : Exposes Service methods as RPC or HTTP interfaces, handling gateway security, traffic control, etc.

Terminal Display Layer : Renders templates for various clients (Velocity, JS, JSP, mobile).

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

Service Layer : Contains concrete business logic.

Manager Layer : General-purpose logic such as third‑party wrappers, caching, middleware handling, and coordination of multiple DAOs.

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

Optimized Layering

Based on practical experience, an ideal model includes:

Controller / TService : Handles lightweight logic, parameter validation, and exception handling; should contain minimal business logic.

Service : Core business layer; each controller method should map to a service method to avoid duplicated orchestration when adding new entry points (e.g., Thrift).

Manager : Reusable logic such as cache, MQ, or composite operations; may also handle data conversion for HTTP or RPC managers.

DAO : Database access layer, exposing only to its corresponding Service.

Domain Model Conversion

Alibaba's guidelines define several domain model types:

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 Service.

AO (Application Object) : Near the presentation layer, low reuse.

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

Query : Data query object; avoid using Map for more than two parameters.

Practical Recommendations

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

Prevent Controller/TService models from being passed directly to DAO, preserving responsibility separation.

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

Conclusion

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable boundaries. While exact conventions may vary across teams, the goal is to keep logic clear, facilitate easy maintenance, and ensure each layer serves its intended purpose.