Application Layering and Domain Model Practices in Backend Development

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

A well‑designed layering approach should be easy to maintain, accepted by the whole team, and have clearly bounded responsibilities for each layer.

Alibaba Coding Specification

Alibaba’s guidelines define the following layers:

Open API layer – exposes Service methods as RPC or HTTP interfaces and handles gateway security and traffic control.

Presentation layer – renders templates for various clients (Velocity, JS, JSP, mobile).

Web layer – performs access control, basic parameter validation, and simple non‑reusable business handling.

Service layer – contains concrete business logic.

Manager layer – provides common business processing such as caching, middleware handling, and aggregates multiple DAOs.

DAO layer – interacts with databases like MySQL, Oracle, HBase.

Although clear, many teams confuse Service and Manager layers, often omitting the Manager layer altogether.

Optimized Layering

Based on practical experience, an improved model adds an extra RPC layer (e.g., Thrift) similar to the controller. The recommended structure is:

Top layer (Controller/TService) – handles lightweight logic, parameter validation, and exception handling; should remain thin to allow easy interface changes.

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

Manager layer – hosts reusable logic such as cache, message queue, or composite operations; HTTP or RPC managers perform necessary data transformations.

DAO layer – dedicated data‑access layer, accessed only by its corresponding service.

Domain Model Conversion

Alibaba defines several domain models:

DO (Data Object) – mirrors database tables, used by DAO.

DTO (Data Transfer Object) – transferred by Service/Manager to external callers.

BO (Business Object) – encapsulates business logic output from Service.

AO (Application Object) – an intermediate, low‑reuse object between Web and Service layers.

VO (View Object) – used by the presentation layer for rendering.

Query – encapsulates query parameters, avoiding Map usage for more than two parameters.

A table summarises the mapping:

Layer

Domain Model

Controller/TService

VO/DTO

Service/Manager

AO/BO

DAO

DO

Strictly adhering to separate models for each layer can cause excessive object conversions (3‑4 times per request). A pragmatic approach allows Service/Manager to work directly with data models while preventing Controllers from passing DAO objects downstream and vice‑versa.

Conclusion

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