Application Layering: Principles, Alibaba Specification, and Optimized Practices

1. Background

Many developers think application layering is simple—just controller, service, mapper—but often blur responsibilities, putting business logic in controllers or using services as pass‑throughs, which leads to tangled code, poor reuse, and maintenance difficulties.

Inconsistent habits among team members cause divergent code styles, making future modifications confusing and error‑prone.

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

2. How to Layer

2.1 Alibaba Specification

Alibaba’s coding guideline defines the following layers:

Open Interface Layer – wraps service methods as RPC or HTTP interfaces, handling gateway security and traffic control.

Terminal Display Layer – template rendering for various clients (Velocity, JS, JSP, mobile).

Web Layer – request routing, basic parameter validation, simple non‑reusable business handling.

Service Layer – concrete business logic.

Manager Layer – generic business processing such as caching, MQ, or composite operations; interacts with DAO.

DAO Layer – data access to MySQL, Oracle, HBase, etc.

In practice many teams omit the Manager layer or confuse Service and Manager responsibilities.

2.2 Optimized Layering

Based on our experience, we propose an ideal model that adds a Thrift‑based TService layer (similar to controller) for lightweight validation and exception handling.

Each controller method should correspond to a distinct service method; business orchestration belongs in the service, not the controller, to avoid duplicated code when switching entry points.

The Manager layer contains reusable logic (caches, MQ, composite queries) and may perform data conversion for HTTP or RPC managers.

DAO remains the sole data‑access layer, accessed only by its own service.

3. Domain Model Conversion Across Layers

Alibaba defines several domain models:

DO (Data Object) – maps directly to database tables.

DTO (Data Transfer Object) – transferred by Service/Manager.

BO (Business Object) – encapsulates business logic output.

AO (Application Object) – used between Web and Service layers, low reuse.

VO (View Object) – passed to view/template engines.

Query – request objects for data queries, avoiding Map for >2 parameters.

Strictly separating models per layer can cause excessive conversions (3‑4 times per request), reducing efficiency.

We recommend a compromise: allow Service/Manager to operate on domain models, forbid passing Controller/TService models to DAO, and likewise prevent DAO models from reaching Controller/TService.

4. Summary

Proper business layering is crucial for code standards, reusability, clear responsibilities, and maintainability. While exact conventions may vary across teams, the key is to keep logic clear and maintenance easy.