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

Background : Many developers assume application layering is simple—just controller, service, and mapper—but responsibilities are often mixed, causing code that is hard to maintain and reuse.

A good layering approach should enable easy maintenance and extension, be accepted by the whole team, and have clear responsibility boundaries.

How to Perform Layering

2.1 Alibaba Specification

Alibaba's coding standards define the following layers:

Open API layer: wraps 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 processing.

Service layer: contains concrete business logic.

Manager layer: provides reusable services such as cache, MQ, or composite operations; also handles data conversion for HTTP/RPC managers.

DAO layer: accesses databases like MySQL, Oracle, HBase.

Although Alibaba's model is clear, many teams still confuse the Service and Manager layers, leading to projects without a distinct Manager layer.

2.2 Optimized Layering

Based on practical experience, an ideal model adds an extra RPC layer (Thrift) that functions similarly to the controller.

1. Controller/TService : Handles light business logic, parameter validation, and exception handling; should remain thin to allow easy swapping of interface types.

2. Service : Holds business logic with low reusability; each controller method should map to a dedicated service method to avoid duplicating orchestration code when adding new entry points (e.g., Thrift).

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

4. DAO : Data access layer that maps database tables to Java objects; should only be accessed by its own Service.

3. Domain Model Conversion Across Layers

Alibaba's guidelines define several domain models:

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

DTO (Data Transfer Object): Transferred by Service or Manager to external callers.

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

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

VO (View Object): Used by the view/template layer.

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 cause an object to be transformed 3‑4 times per request, dramatically reducing development efficiency.

Practical compromise:

Allow Service/Manager layers to operate directly on domain models for business processing and data assembly.

Prohibit Controller/TService from passing domain models to DAO, preserving layer responsibilities.

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

4. Summary

Proper backend layering is crucial for code reuse, clear responsibilities, and maintainability. While exact conventions may vary across teams, the key is to keep each layer’s logic distinct and ensure easy future maintenance.

Different teams may adopt different layering habits, but as long as responsibilities are clear and maintenance is straightforward, the layering can be considered effective.

If you have better layering practices or notice any errors, feel free to comment.

PS: If you found this sharing useful, please like and share.