Mastering Backend Layering: From Alibaba Specs to Practical Optimizations

1. Background

Many developers treat application layering as a simple three‑tier structure (controller, service, mapper) without clearly separating responsibilities, leading to tangled code, poor reuse, and difficult maintenance.

A good layering approach must enable easy maintenance and extension, be accepted by the whole team, and have clearly defined boundaries for each layer.

2. How to Layer

2.1 Alibaba Specification

Alibaba’s coding standard 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 : Renders templates for various clients (Velocity, JS, JSP, mobile, etc.).

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

Service Layer : Contains concrete business logic with low reuse.

Manager Layer : Provides reusable logic such as caching, messaging, or composite operations; also handles data conversion for HTTP/RPC managers.

DAO Layer : Interacts with databases (MySQL, Oracle, HBase) and maps tables to Java objects.

In practice, the distinction between Service and Manager layers is often blurred, and many projects omit the Manager layer entirely.

2.2 Optimized Layering

Our projects use Thrift as the RPC framework, which adds an extra layer similar to a controller:

Top‑level Controller/TService : Handles lightweight logic, parameter validation, and exception handling; should remain thin to allow easy interface replacement.

Service : Implements business logic; each controller method should map to a distinct service method to avoid duplicating orchestration when adding new entry points.

Manager : Encapsulates reusable logic (e.g., cache, MQ) and can combine multiple managers for complex operations; performs data conversion for HTTP or RPC managers.

DAO : Provides data access; only its corresponding service should invoke DAO methods, preventing direct DAO access from controllers.

3. Domain Model Conversion

Alibaba’s specification defines several domain models:

DO (Data Object) : Directly maps to database tables and is transferred via the DAO layer.

DTO (Data Transfer Object) : Used by Service or Manager to transfer data outward.

BO (Business Object) : Encapsulates business logic output from the Service layer.

AO (Application Object) : An application‑level object between Web and Service layers, with low reuse.

VO (View Object) : Sent to the presentation layer for rendering.

Query : Encapsulates query parameters; multi‑parameter queries should avoid using generic Map objects.

Excessive conversions across layers can lead to three or four transformations per request, dramatically increasing code churn.

Compromise Solution :

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

Prohibit Controllers/TService from passing their domain models to the DAO layer.

Similarly, prevent DAO data from being passed directly to Controllers/TService.

4. Summary

Effective application layering is crucial for code reuse, clear responsibilities, and maintainable boundaries. While the exact layering scheme may vary across teams, any approach that keeps responsibilities distinct and simplifies future maintenance qualifies as a good layering strategy.