Best Practices for Application Layering and Domain Model Design

1. Background

When people talk about application layering, many assume it is simple: controller, service, and mapper layers. In practice, responsibilities are often blurred; controllers sometimes contain more logic than services, and services become mere pass‑throughs, leading to poor reuse, tangled hierarchy, and difficult maintenance.

Some developers follow existing code styles without questioning them, which results in inconsistent coding habits across a team. This inconsistency makes future modifications confusing and can cause friction among team members.

A good layering approach should:

Facilitate future maintenance and extension.

Be accepted by the whole team.

Define clear boundaries for each layer's responsibilities.

2. How to Layer

2.1 Alibaba Specification

Alibaba's coding guidelines define the following layers:

Open Interface Layer : Exposes Service methods as RPC or HTTP interfaces, handling gateway security, traffic control, etc.

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 with relatively low reuse.

Manager Layer : General business handling, such as third‑party platform wrappers, common capabilities (caching, middleware), and coordination of multiple DAOs.

DAO Layer : Data access layer that interacts with MySQL, Oracle, HBase, etc.

Although Alibaba's model is clear, many teams omit the Manager layer because its purpose is often misunderstood.

2.2 Optimized Layering

Based on our own projects (using Thrift as the RPC framework), we propose a slightly different model. The topmost controller/TService layer should contain only light business logic, parameter validation, and exception handling, allowing easy replacement of the entry point.

Service : Holds business logic; each controller method should map to a dedicated service method to avoid duplicating orchestration code when adding new entry points.

Manager : Reusable logic such as cache, MQ, or composite operations that may involve multiple managers; HTTP or RPC managers perform necessary data transformations.

DAO : Database access; only the corresponding Service should call its DAO, and other Services must go through the Service layer.

3. Domain Model Conversion Across Layers

Alibaba's guidelines list several domain models:

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

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

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

AO (Application Object): Near‑presentation objects used between Web and Service layers, with low reuse.

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

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

Strictly separating these models can lead to excessive conversions—sometimes three or four transformations per request—causing unnecessary boilerplate.

4. Summary

Proper application layering is crucial for code standards, reusability, and clear responsibility boundaries. While exact conventions may vary among teams, the key is to keep each layer’s duties well defined so that maintenance remains straightforward.