Best Practices for Application Layering in Backend Development

Application Layering Overview

Many developers treat layering as a simple three‑tier structure (controller, service, mapper), but responsibilities are often blurred, leading to tangled code, poor reuse, and maintenance headaches.

1. Background

Clear layering improves maintainability and extensibility.

The whole team must accept the layering approach.

Each layer should have well‑defined boundaries.

2. How to Layer

2.1 Alibaba Specification

Alibaba’s coding guidelines define the following layers:

Open Interface Layer : Exposes RPC or HTTP interfaces, handles gateway security and traffic control.

Terminal Display Layer : Template rendering for various front‑ends (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 low reuse.

Manager Layer : Provides reusable services such as caching, MQ handling, and aggregates multiple DAOs.

DAO Layer : Direct data access to MySQL, Oracle, HBase, etc.

2.2 Optimized Layering

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

Controller/TService : Light business logic, parameter validation, and exception handling; should remain thin to allow easy replacement of the entry point.

Service : Core business logic; each controller method should map to a distinct service method to avoid duplicated orchestration code when switching protocols.

Manager : Reusable logic such as cache, MQ, or composite operations; may include HTTP or RPC managers that handle data conversion.

DAO : Direct database access; only the corresponding service should invoke its DAO.

3. Domain Model Conversion

Alibaba’s guidelines define several domain model types and their typical layer mappings:

DO (Data Object): Directly maps to database tables, used in the DAO layer.

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

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

AO (Application Object): Reusable object between Web and Service layers, close to the presentation layer.

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

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

Layer

Domain Model

Controller/TService

VO/DTO

Service/Manager

AO/BO

DAO

DO

Strictly separating models can lead to excessive conversions (3‑4 times per request). A pragmatic approach is to allow Service/Manager layers to work directly with DOs when appropriate, while keeping clear boundaries: Controllers should not access DAOs directly, and DAOs should not return objects to Controllers.

4. Summary

Proper application layering is crucial for code reuse, clear responsibilities, and maintainable architecture. While exact conventions may vary across teams, the key is to ensure each layer’s duties are well defined and the codebase remains easy to extend and refactor.

Feel free to share your own layering practices or point out any inaccuracies.