Best Practices for Application Layering in Backend Development

In modern backend development, clear separation of responsibilities across layers is essential for maintainability and reusability. Many teams mistakenly blur the boundaries between controller, service, and mapper layers, leading to tangled code and difficult maintenance.

The author presents Alibaba's coding guidelines as a reference, defining a six‑tier architecture:

Open API Layer : Exposes service methods as RPC or HTTP interfaces and handles gateway security and traffic control.

Presentation Layer : Renders templates for various front‑ends (Velocity, JS, JSP, mobile).

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 utilities such as caching, MQ handling, and composite operations; also adapts data for HTTP/RPC managers.

DAO Layer : Directly accesses databases (MySQL, Oracle, HBase) and maps tables to Java objects.

While Alibaba's model is clear, the author notes that many projects omit the Manager layer and misuse Service and Controller responsibilities. An optimized layering approach is proposed, adding a TService layer (lightweight business logic, parameter validation, exception handling) and encouraging each controller method to correspond to a dedicated service method to avoid duplicated orchestration code.

The article also reviews domain model conventions used in layered architectures, including DO (Data Object), DTO (Data Transfer Object), BO (Business Object), AO (Application Object), VO (View Object), and Query objects, warning against excessive object conversions across layers.

In summary, a well‑designed layered architecture should be easy to maintain, have clear boundaries, and be accepted by the whole team; adhering to these principles improves code reuse and reduces future maintenance overhead.