Application Layering Best Practices and Alibaba Specification

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

Key requirements for a good layering strategy :

Facilitates future maintenance and extension.

Is accepted by the whole team.

Defines clear boundaries for each layer's responsibilities.

Alibaba coding specification 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 : Handles template rendering for web, JS, JSP, mobile, etc.

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

Service Layer : Contains concrete business logic.

Manager Layer : Provides generic services such as third‑party integration, caching, middleware handling, and aggregates multiple DAOs.

DAO Layer : Direct data access to MySQL, Oracle, HBase, etc.

Optimized layering in practice – When using RPC frameworks like Thrift, an extra layer similar to a controller appears. The recommended approach is:

Keep the topmost controller/TService lightweight, handling only parameter validation and exception handling.

Place business logic in the Service layer, ensuring each controller method maps to a distinct service method.

Encapsulate reusable logic in Manager classes (e.g., cache, MQ, composite queries).

Restrict DAO access to its own Service; other Services must go through the appropriate Service layer.

Domain model conversion – Alibaba defines several models (DO, DTO, BO, AO, VO, Query). Over‑using conversions across layers can cause excessive object transformations; a pragmatic compromise is to allow Service/Manager layers to work directly with domain models while preventing Controllers and DAOs from crossing each other's boundaries.

Conclusion – Proper layering improves code reuse, clarifies responsibilities, and simplifies maintenance. While exact conventions may vary between teams, adhering to clear boundaries and minimizing unnecessary object conversions leads to a cleaner, more maintainable backend architecture.