Application Layering and Domain Model Conversion: Best Practices and Alibaba Specification

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 reusability, and maintenance difficulties.

In real teams, personal habits cause inconsistent layer implementations, making future modifications confusing and error‑prone.

A good layering approach should be maintainable, extensible, accepted by the whole team, and have clear boundaries.

Facilitate future maintenance and extension.

Be accepted by the entire team.

Define clear responsibilities 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, handling gateway security and traffic control.

Terminal Display Layer: Template rendering for various front‑ends (Velocity, JS, JSP, mobile).

Web Layer: Handles access control, basic parameter validation, and simple business processing.

Service Layer: Contains concrete business logic.

Manager Layer: General business processing (third‑party integration, caching, middleware handling) and interacts with DAO.

DAO Layer: Data access, interacting with MySQL, Oracle, HBase, etc.

Although clear, many teams overlook the distinction between Service and Manager layers, often omitting the Manager layer entirely.

2.2 Optimized Layering

Based on our experience (using Thrift as the RPC framework), we propose a refined model:

Top‑level Controller/TService: Performs lightweight business logic, parameter validation, and exception handling; should remain simple to allow easy interface swapping.

Service: Handles business logic with low reusability; each controller method should map to a dedicated service to avoid duplicating orchestration logic when adding new entry points.

Manager: Encapsulates reusable logic such as caching, MQ, or composite operations; HTTP or RPC managers may also perform data transformation.

DAO: Pure data‑access layer, accessed only by its corresponding Service.

By moving orchestration into Service, we reduce repetitive code and improve development efficiency.

3. Domain Model Conversion

Alibaba’s specification lists several domain models:

DO (Data Object): Directly maps to database tables, transferred via DAO.

DTO (Data Transfer Object): Used for data exchange from Service/Manager to external callers.

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

AO (Application Object): Reusable object model between Web and Service layers, closely tied to presentation.

VO (View Object): Object passed to template rendering engines.

Query: Encapsulates query parameters, avoiding Map usage for more than two parameters.

Layer

Domain Model

Controller/TService

VO/DTO

Service/Manager

AO/BO

DAO

DO

Strictly converting objects at every layer can cause 3‑4 transformations per request, leading to inefficiency. A pragmatic approach is recommended:

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

Prevent Controller/TService from passing DAO‑level objects downstream.

Similarly, DAO should not expose its objects to Controller/TService.

4. Summary

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable boundaries. While exact standards may vary across teams, the key is to ensure logical clarity and ease of future maintenance.

We welcome feedback on better layering practices or corrections to the described approach.