Mastering Application Layering: From Alibaba Standards to Practical Optimizations

Background

Many developers assume that application layering is trivial—just controller, service, and mapper—but responsibilities are often blurred, with controllers handling business logic and services acting as simple pass‑throughs. This leads to tangled code, poor reusability, and difficult maintenance.

Key Requirements for a Good Layered Architecture

Facilitates future maintenance and extension.

Is accepted and understood by the whole team.

Defines clear boundaries for each layer’s responsibilities.

2. How to Structure Layers

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 concrete business logic.

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

DAO Layer : Directly accesses databases like MySQL, Oracle, HBase.

2.2 Optimized Layering

Based on our own projects and the use of Thrift as the RPC framework (which adds a layer similar to a controller), we propose the following refined structure:

The topmost Controller/TService layer should contain only lightweight logic: parameter validation and exception handling. Business orchestration belongs in the Service layer.

Each controller method should map to a dedicated service method to avoid duplicated orchestration when adding new entry points (e.g., another RPC protocol).

The Manager layer hosts reusable logic such as caching, message queues, or composite services that may combine multiple managers. HTTP or RPC managers perform necessary data transformations.

The DAO layer is responsible solely for database interactions and should only be accessed by its corresponding Service.

3. Domain Model Conversion Across Layers

Alibaba’s guidelines also define several domain model types:

DO (Data Object) : Direct mapping 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 used between Web and Service layers, with low reuse.

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

Query : Encapsulates query parameters; avoid using generic Maps for more than two parameters.

Applying a model per layer can lead to excessive object conversions—sometimes three to four times per request—causing unnecessary overhead.

4. Recommendations and Summary

To balance clarity and efficiency, we suggest:

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

Prevent Controller/TService models from being passed directly to DAO.

Similarly, DAO models should not be fed into Controller/TService.

In conclusion, a well‑designed layering scheme improves code reuse, clarifies responsibilities, and simplifies maintenance. While team habits vary, the essential goal is clear boundaries and easy extensibility.