Application Layering Best Practices and Alibaba Specification

When people talk about application layering, many assume it is simple—just controller, service, and mapper layers—but in practice responsibilities are often blurred, leading to tangled code that is hard to maintain and reuse.

Some developers follow existing code styles without questioning them, resulting in inconsistent layer usage across a team; this makes future modifications confusing and error‑prone.

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

Alibaba Specification

The Alibaba coding guideline defines the following layers:

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

Terminal Display Layer: renders templates for various front‑ends (Velocity, JS, JSP, mobile, etc.).

Web Layer: performs access control, basic parameter validation, and simple business handling.

Service Layer: contains concrete business logic.

Manager Layer: generic business processing (e.g., third‑party wrappers, caching, middleware handling) and interacts with DAO.

DAO Layer: data access, communicating with MySQL, Oracle, HBase, etc.

Although the Alibaba model is clear, many teams omit the Manager layer or confuse Service and Manager responsibilities.

Optimized Layering

Based on our own projects, we propose an improved model (note that our RPC framework is Thrift, which adds an extra layer similar to a controller):

The topmost Controller and TService layers should contain only lightweight logic, parameter validation, and exception handling, leaving business orchestration to the Service layer.

Each controller method should correspond to a dedicated service method; otherwise, adding a new entry point (e.g., Thrift) would require duplicating business logic.

Placing business orchestration in the Service layer avoids massive code duplication and improves development efficiency.

The Manager layer hosts reusable logic such as caching, MQ, or composite operations that may involve multiple managers; HTTP or RPC managers perform necessary data transformations.

The DAO layer is responsible for database access and should only be called by its corresponding Service.

Domain Model Conversion

Alibaba’s guideline lists several domain models:

DO (Data Object): one‑to‑one with database tables, transferred via DAO.

DTO (Data Transfer Object): transferred by Service or Manager to external callers.

BO (Business Object): encapsulates business logic output from Service.

AO (Application Object): a low‑reuse object between Web and Service layers, close to the presentation layer.

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

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

Strictly separating these models can cause excessive conversions—sometimes three or four times per request—leading to unnecessary overhead.

We recommend a compromise:

Allow Service/Manager layers to operate on data domain models, as they already handle business processing and data assembly.

Prohibit passing Controller/TService domain models directly to DAO.

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

Conclusion

Proper layering is crucial for code reusability, clear responsibilities, and maintainable boundaries. While the exact layering scheme may vary between teams, the key is to keep logic clear and maintenance easy.