Best Practices for Application Layering in Backend Development

1. Background Many developers treat application layering as a simple three‑tier structure (controller, service, mapper) without clearly separating responsibilities, leading to tangled code, poor reuse, and maintenance difficulties.

The article lists three essential criteria for a good layering approach: easy maintenance and extension, team-wide acceptance, and clear boundary definitions for each layer.

2. How to Layer

2.1 Alibaba Specification The Alibaba coding guidelines define the following layers:

Open Interface Layer : Exposes Service methods as RPC or HTTP interfaces, handling 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 low reuse.

Manager Layer : Provides reusable logic such as third‑party integrations, caching, middleware handling, and combines multiple DAOs.

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

Although the Alibaba model is clear, many teams still confuse Service and Manager responsibilities, often omitting the Manager layer.

2.2 Optimized Layering The article proposes an improved model that accounts for RPC frameworks (e.g., Thrift) and emphasizes:

Controller/TService should contain only lightweight logic: parameter validation and exception handling.

Each controller method should correspond to a distinct Service method to avoid duplicated business orchestration across entry points.

Service layer should encapsulate all business orchestration, improving reusability.

Manager layer hosts reusable components (cache, MQ, composite queries) and handles data conversion for HTTP/RPC managers.

最近面试BAT，整理一份面试资料
《
Java面试BAT通关手册
》
，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“
在看
”，关注公众号并回复
手册
领取，更多内容陆续奉上。

3. Domain Model Conversion The article lists common domain model types used across layers:

DO (Data Object) – maps directly 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) – a reusable model between Web and Service, close to the presentation layer.

VO (View Object) – used by the view/template layer.

Query – request objects for data retrieval, avoiding Map usage for >2 parameters.

Excessive conversion between these models can lead to multiple transformations per request, reducing efficiency.

4. Summary Proper layering and clear domain model boundaries are crucial for maintainable, reusable code. While exact conventions may vary among teams, the key is to keep responsibilities distinct, minimize duplicated business logic, and ensure that each layer’s model is used appropriately.

The article also invites readers to join a top‑architect community, offers promotional gifts, and provides links to related resources.