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

1. Background

Many developers assume that a simple three‑layer architecture (controller, service, mapper) is sufficient, but in practice responsibilities are often mixed: controllers contain business logic, services become mere pass‑throughs, and the lack of clear boundaries leads to tangled code that is hard to reuse and maintain.

Team members have different habits—some embed heavy logic in controllers, others call remote services from services—resulting in inconsistent code styles that make future modifications difficult and error‑prone.

A good application layering should:

Facilitate maintenance and extension of the codebase.

Be accepted by the entire development team.

Define clear responsibility boundaries for each layer.

2. How to Perform Layering

2.1 Alibaba Specification

Alibaba’s coding guidelines define the following layers:

Open API Layer: Exposes service methods as RPC or HTTP interfaces and 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: Provides generic business processing such as third‑party integration, caching, middleware handling, and composite DAO operations.

Encapsulates third‑party platform calls and normalizes exceptions.

Offers common capabilities like caching and middleware processing.

Coordinates multiple DAO interactions.

DAO Layer: Directly accesses databases such as MySQL, Oracle, or HBase.

While Alibaba’s model is clear, many teams still confuse Service and Manager layers, leading to the omission of a Manager layer in practice.

2.2 Optimized Layering

Based on our own projects (using Thrift as the RPC framework, which adds an extra layer similar to a controller), we propose the following refined model:

Top‑most Controller/TService: Handles lightweight logic, parameter validation, and exception handling. It should remain thin so that the underlying interface can be swapped easily.

Service: Implements business logic with low reuse; each controller method should map to a distinct service method. Business orchestration belongs here, not in the controller, to avoid duplicated code when adding new entry points (e.g., Thrift).

Placing orchestration in Service eliminates repetitive code across different entry layers.

Manager: Holds reusable logic such as caching, messaging, or composite operations. It can be a single‑service manager (e.g., CacheManager) or a composite manager that aggregates multiple services.

DAO: Provides data‑access objects that map database tables to Java objects. Only the corresponding Service should directly call its DAO; other Services must go through the Service layer.

3. Domain Model Conversion Across Layers

Alibaba’s guidelines define several domain‑model types:

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

DTO (Data Transfer Object): Used by Service or Manager to expose data outward.

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

AO (Application Object): Close to the presentation layer, low reuse, used between Web and Service.

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

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

Strictly separating models per layer can cause excessive conversions (3‑4 times per request). To avoid this, we recommend a compromise:

Allow Service/Manager layers to manipulate domain models directly, since they already handle business processing and data assembly.

Prevent Controller/TService models from being passed to DAO.

Similarly, DAO models should not be sent directly to Controller/TService.

4. Conclusion

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable architecture. While the exact layering scheme may vary between teams, the key is to keep each layer’s responsibilities well defined and to ensure that the codebase remains easy to extend and maintain.