Mastering Application Layering: From Alibaba Specs to Practical Backend Architecture

Background

Many teams treat application layering as a simple three‑tier structure (controller, service, mapper) without clearly separating responsibilities. This often results in controllers containing business logic while services become thin pass‑throughs, which reduces code reuse and makes maintenance difficult.

Layering guidelines

Alibaba specification

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

Terminal Display 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 with relatively low reuse.

Manager Layer : Provides reusable logic such as caching, MQ handling, or composite operations; interacts with multiple DAOs.

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

Optimized layering for Thrift

When the RPC framework is Thrift, an additional layer similar to a controller (TService) appears. A practical structure is:

Controller / TService : Very light logic – only parameter validation, exception handling, and delegating to the Service layer. It should be easy to replace with another transport.

Service : Orchestrates full business processes. Each controller method should map to a distinct service method to avoid duplicated orchestration code when new entry points (e.g., another RPC protocol) are added.

Manager : Encapsulates reusable components such as cache, MQ, or composite operations. HTTP or RPC managers may also perform data‑format conversion.

DAO : Pure data‑access layer; only the corresponding Service should call its DAO.

Placing orchestration in the Service layer eliminates repetitive code when new interfaces (e.g., Thrift) are introduced.

Domain model types

Alibaba’s coding guidelines define several model objects that should be used at appropriate layers:

DO (Data Object) : Direct mapping to database tables; passed through the DAO layer.

DTO (Data Transfer Object) : Objects transferred from Service or Manager to callers.

BO (Business Object) : Encapsulates the result of business logic produced by the Service layer.

AO (Application Object) : Near‑presentation objects used between Web and Service layers; low reuse.

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

Query : Parameter objects for data queries; avoid using generic Map when more than two parameters are needed.

Practical compromise

Strictly following the model conversion rules can lead to 3‑4 object transformations per request, which hurts performance. A pragmatic approach is to allow Service and Manager layers to work directly with domain models (DO/BO) while enforcing that Controllers/TService and DAO layers never cross responsibilities. This keeps orchestration clear and reduces unnecessary conversions.

Summary

A well‑defined layering strategy improves code reuse, clarifies responsibilities, and simplifies future maintenance. Teams should adopt a layering model that all members understand, keep clear boundaries between layers, and place orchestration logic in the Service layer to avoid duplication across different entry points.