Application Layering and Domain Model Transformation: Guidelines and Best Practices

1. Background

Many developers think layering is simple—just controller, service, and mapper—but responsibilities are often mixed, leading to tangled code, poor reusability, and maintenance difficulties. Inconsistent habits across team members make it hard to modify code consistently, causing frustration and potential errors.

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

Facilitate future maintenance and extension.

Be understandable and adoptable by the entire team.

Define clear responsibilities for each layer.

2. How to Layer

2.1 Alibaba Specification

Alibaba’s coding guidelines define the following layers:

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

Presentation Layer: Renders templates for various clients (Velocity, JS, JSP, mobile, etc.).

Web Layer: Performs request routing, basic parameter validation, and simple non‑reusable business handling.

Service Layer: Contains concrete business logic.

Manager Layer: Handles generic business processing such as third‑party integration, caching, middleware utilities, and aggregates multiple DAOs.

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

Although the Alibaba model is clear, many teams omit the Manager layer or confuse Service and Manager responsibilities.

2.2 Optimized Layering

Based on our own projects (using Thrift as the RPC framework), we propose an improved model that adds an extra TService layer similar to a controller.

1. Top layer (Controller/TService): Light business logic, parameter validation, and exception handling. It should remain thin to allow easy swapping of interface types.

2. Service layer: Core business logic; each controller method should map to a dedicated service method to avoid duplicating orchestration code when adding new entry points.

3. Manager layer: Reusable logic such as cache, MQ, or composite operations (e.g., multi‑table queries). HTTP or RPC managers may also perform data transformation.

4. DAO layer: Direct database access; only the corresponding service should call its DAO, and other services must go through the service layer.

3. Domain Model Transformation Across Layers

Alibaba’s guidelines define several domain objects:

DO (Data Object): Mirrors database tables, transferred via DAO.

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

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

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

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

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

Layer

Domain Model

Controller/TService

VO/DTO

Service/Manager

AO/BO

DAO

DO

Strictly following these conversions can lead to 3‑4 transformations per request, which is inefficient.

We recommend a compromise:

Allow Service/Manager to work directly with DO when appropriate, since they already handle business assembly.

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

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

4. Summary

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable systems. While exact conventions may vary across teams, the key is to keep each layer’s purpose distinct and ensure the architecture supports easy maintenance and extension.

If your team has a better layering approach or finds errors in this description, feel free to share your feedback.