Application Layering Principles and Practices in Backend Architecture

1. Background

Many developers think application layering is simple—just controller, service, and mapper—but often blur responsibilities, leading to controllers handling too much logic and services becoming mere pass‑throughs, which harms code reuse and maintenance.

In practice, personal habits cause inconsistent layer implementations, making it hard for others to modify code without conflict.

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 Perform Layering

2.1 Alibaba Specification

Alibaba’s coding standards 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 handling.

Service Layer : Contains concrete business logic with low reuse.

Manager Layer : General business processing, including third‑party platform wrappers, common capabilities (caching, middleware), and DAO composition.

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

In many projects the Manager layer is omitted, causing confusion between Service and Manager responsibilities.

2.2 Optimized Layering

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

The topmost controller/TService should handle only light business logic, parameter validation, and exception handling, keeping the interface easily replaceable.

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

Placing orchestration logic in the Service layer prevents massive code duplication and improves development efficiency.

Manager : Reusable logic layer (e.g., cache, MQ). Can be single‑service or composite when multiple managers are needed; HTTP or RPC managers perform data conversion here.

DAO : Database access layer, exposing only to its own Service; other Services must go through the Service layer.

3. Domain Model Transformations 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/Manager to transfer data outward.

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

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

VO (View Object): Presentation‑layer object for template rendering.

Query: Data query object; avoid using Map for more than two parameters.

Strictly following these models can cause excessive conversions (3‑4 times per request), leading to unnecessary boilerplate.

We propose a compromise:

Allow Service/Manager to operate on data domain models, as they already handle business assembly.

Prevent Controller/TService models from being passed into DAO, preserving responsibility boundaries.

Similarly, DAO data should not be passed directly to Controller/TService.

4. Summary

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable boundaries; while exact standards may vary across teams, the key is to keep logic clear and maintenance easy.

Overall, a well‑designed layer structure improves code quality and reduces future technical debt.