Application Layering: Principles, Alibaba Specification, and Domain Model Conversion

Background: Many developers mistakenly treat application layering as a simple three‑layer structure (controller, service, mapper) without clear responsibilities, leading to tangled code that is hard to maintain and reuse.

Effective layering should be maintainable, accepted by the whole team, and have clear boundaries between layers.

How to Layer

2.1 Alibaba Specification

Alibaba’s coding guidelines define the following layers:

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

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

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

Service Layer: Contains specific business logic.

Manager Layer: General business processing such as third‑party integration, caching, middleware handling, and coordination of multiple DAOs.

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

Although Alibaba’s model is clear, many teams still confuse Service and Manager layers, often omitting the Manager layer altogether.

2.2 Optimized Layering

Based on our experience (using Thrift RPC), we propose a slightly different model where the topmost controller/TService handles only lightweight logic, parameter validation, and exception handling.

Each controller method should correspond to a dedicated Service method; business orchestration belongs in Service to avoid duplication when adding new entry points.

Manager (or “Mannager”) is a reusable logic layer for cache, MQ, or composite operations, handling data transformation for HTTP or RPC managers.

DAO remains the data‑access layer, accessed only by its Service.

Domain Model Conversion

Alibaba’s guidelines define several domain object 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‑presentation objects with low reuse, used between Web and Service layers.

VO (View Object): Objects passed to view templates.

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

Strictly separating these models can cause excessive conversions (3‑4 times per request). A pragmatic approach is to allow Service/Manager to work with data domain models while preventing Controller/TService from passing objects directly to DAO and vice‑versa.

Conclusion

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable boundaries. While team habits vary, the key is to keep responsibilities clear and make future maintenance easy.