Best Practices for Application Layering and Domain Model Conversion in Backend Development

Background – Many developers treat layering (controller, service, mapper) as a formality, often mixing responsibilities, which leads to tangled code, poor reuse, and maintenance difficulties.

A well‑designed layering should be easy to maintain, accepted by the whole team, and have clear boundaries between responsibilities.

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.

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

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

Service Layer : Contains concrete business logic.

Manager Layer : Provides generic services such as third‑party integrations, caching, middleware handling, and aggregates multiple DAOs.

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

Although clear, the Alibaba model often blurs the distinction between Service and Manager layers, leading some projects to omit the Manager layer entirely.

2.2 Optimized Layering

Based on practical experience, an ideal model adds a thin controller/TService layer for lightweight logic, parameter validation, and exception handling. The Service layer should host business logic and avoid duplication across entry points (e.g., when adding a Thrift interface).

The Manager layer contains reusable logic such as caching, messaging, or composite operations that may involve multiple managers; HTTP or RPC managers perform necessary data transformations.

The DAO layer remains the sole data‑access component, exposing only its own Service to other layers.

Domain Model Conversion Across Layers

Alibaba’s specification defines several domain objects:

DO (Data Object) – Direct mapping to database tables, used by DAO.

DTO (Data Transfer Object) – Objects transferred from Service/Manager outward.

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

AO (Application Object) – Reusable model between Web and Service layers, close to the presentation tier.

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

Query – Query objects for data retrieval, avoiding Map usage for multiple parameters.

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), harming performance and developer productivity.

Practical Compromise

Allow Service/Manager layers to operate on domain models directly, since they already handle business logic and data assembly.

Prevent Controller/TService from passing objects directly to DAO; this would violate responsibility separation.

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

Conclusion

Proper application layering is crucial for code reuse, clear responsibilities, and maintainability. While exact conventions may vary between teams, the key is to keep logic boundaries clear and ensure that each layer can be maintained and extended independently.

Feedback and alternative layering strategies are welcome.