Best Practices for Application Layering and Domain Model Design

1. Background

Many developers treat the three‑tier structure (controller, service, mapper) as a simple formality and often blur responsibilities, leading to controllers containing business logic, services acting as pass‑throughs, and overall code that is hard to reuse and maintain.

Inconsistent personal habits further exacerbate the problem, as each developer may place logic in different layers, making later modifications confusing and error‑prone.

2. How to Perform Layering

2.1 Alibaba Specification

Alibaba’s coding guidelines define 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 request routing, basic parameter validation, and simple non‑reusable business handling.

Service Layer : Contains concrete business logic with relatively low reusability.

Manager Layer : Provides reusable logic such as third‑party integrations, caching, middleware handling, and composite DAO operations.

DAO Layer : Directly accesses databases like MySQL, Oracle, HBase.

Although the specification is clear, many teams still confuse the boundaries between Service and Manager, resulting in missing Manager layers in projects.

2.2 Optimized Layering

Based on our experience with Thrift RPC (which adds an extra layer similar to a controller), we propose the following refined model:

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

Service : Implements core business logic; each controller method should map to a distinct service method to avoid duplicated orchestration when new entry points (e.g., Thrift) are added.

Manager : Encapsulates reusable components such as cache, MQ, or composite operations; can be combined when multiple managers are needed.

DAO : Provides data‑access objects; only the corresponding Service should call its DAO, preventing cross‑layer data leakage.

3. Layer Domain Model Conversion

Alibaba’s domain model conventions include:

DO (Data Object): Directly maps to database tables.

DTO (Data Transfer Object): Used for data exchange between Service/Manager and external callers.

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

AO (Application Object): Near‑presentation objects with low reusability.

VO (View Object): Objects passed to the view/template layer.

Query: Encapsulates query parameters, avoiding Map usage for more than two parameters.

Strictly following these conversions can lead to excessive object transformations (3‑4 times per request), dramatically increasing development effort.

We recommend a pragmatic compromise:

Allow Service/Manager to manipulate domain models directly when assembling business data.

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

Disallow DAO from returning objects directly to Controller/TService.

4. Summary

Proper application layering is crucial for code reuse, clear responsibility boundaries, and maintainability. While exact conventions may vary across teams, a well‑accepted layering strategy that keeps each layer’s duties distinct and the domain model flow sensible leads to healthier backend systems.