Mastering Application Layering: Practical Guide to Clean Backend Architecture

1. Background

When discussing application layering, many assume it's simple—controller, service, mapper—but responsibilities are often blurred; controllers sometimes contain more logic than services, and services become mere pass‑throughs, leading to tangled code, poor reusability, and maintenance headaches.

In practice, each developer’s habits cause inconsistent layer implementations, making future modifications confusing and error‑prone.

Key requirements for a good application layer

Facilitate future maintenance and extension.

Be accepted by the whole team.

Clearly define the responsibilities of each layer.

2. How to structure layers

2.1 Alibaba specification

Alibaba’s coding guideline defines the following layers:

Open Interface Layer: Wraps 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 request routing, basic parameter validation, and simple non‑reusable business handling.

Service Layer: Contains concrete business logic.

Manager Layer: General business processing with features such as:

Encapsulates third‑party platform calls, preprocesses results, and translates exceptions.

Provides common capabilities for the service layer (caching, middleware handling).

Interacts with DAO layer and reuses multiple DAOs.

DAO Layer: Data access, interacting with MySQL, Oracle, HBase, etc.

Although Alibaba’s model is clear, many teams omit the Manager layer or confuse Service and Manager responsibilities.

2.2 Optimizing the layering

Our experience with Thrift RPC adds an extra layer similar to a controller. The topmost controller/TService should contain only lightweight logic, parameter validation, and exception handling, making it easy to replace the interface type.

Service: Business layer with low reuse; each controller method should map to a distinct service method. Embedding orchestration logic in controllers leads to duplicated code when adding new entry points (e.g., Thrift).

Therefore, business orchestration should reside in the Service layer.

Manager: Reusable logic layer (e.g., cache, MQ). It can be single‑purpose or composite, handling data conversion for HTTP or RPC managers.

DAO: Database access layer; only its corresponding Service should call it.

3. Domain model conversion across layers

Alibaba’s specification lists several domain models:

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

DTO (Data Transfer Object): Objects sent from Service/Manager to external callers.

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 Map for more than two parameters.

Strictly separating these models can cause excessive conversions—an object may be transformed three or four times in a single request, dramatically increasing boilerplate code.

4. Summary

Proper application layering is crucial for code reuse, clear responsibilities, and maintainability. While teams may have different habits, a good layer design should keep logic clear, facilitate future maintenance, and avoid unnecessary duplication.