Multi-Layer Invocation Example: Four-Tier Architecture and Best Practices

Layered architecture is one of the most fundamental patterns in backend development. By partitioning code into distinct

Layered architecture is one of the most fundamental patterns in backend development. By partitioning code into distinct layers based on specific responsibilities, developers can achieve clearer boundaries, enhanced maintainability, and superior testability. This article explores the classic four-layer architecture, demonstrates a complete execution flow, and outlines industry best practices for multi-layer calling.
A typical four-layer architecture organizes a system from the top (user-facing) to the bottom (data-facing):

  1. Presentation Layer: This is the entry point of the application. It is responsible for receiving HTTP requests, validating input parameters, and encapsulating the final response. In modern frameworks, this is commonly implemented via Controllers.
  2. Business Logic Layer (Service Layer): This layer acts as the "brain" of the application. It carries out core business rules, manages transaction boundaries, and orchestrates complex workflows. It is typically implemented through Services.
  3. Data Access Layer (DAL): This layer handles all interactions with the persistence mechanism. It abstracts the complexities of CRUD (Create, Read, Update, Delete) operations. Common implementations include DAOs (Data Access Objects) or Repositories.
  4. Data Storage Layer: This is the actual physical storage, such as a Relational Database (RDBMS) or a NoSQL engine, responsible for the long-term persistence of data.

The Golden Rule of Layering: Dependencies must strictly flow downward. The Presentation layer calls the Service layer, which in turn calls the Data Access layer, which finally interacts with the Database. Any "skip-layer" calls (e.g., Controller calling DAO directly) or "upward" calls (e.g., DAO calling Service) violate architectural boundaries and lead to technical debt.

A Complete Call Chain Example

To illustrate how a request traverses these layers, let's examine a common scenario: "Fetching a user by their unique ID."

1. Presentation Layer

The Controller handles the web request and delegates the heavy lifting to the service.

@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping("/{id}")
    public Result<UserVO> getUser(@PathVariable Long id) {
        // Perform basic validation and delegate to the Service layer
        return Result.success(userService.getUserById(id));
    }
}

2. Business Logic Layer

The Service layer retrieves the raw data, applies business logic (such as checking if the user exists), and transforms the data into a format suitable for the client.

@Service
public class UserServiceImpl implements UserService {

    @Autowired
    private UserDao userDao;

    @Override
    public UserVO getUserById(Long id) {
        // Retrieve the persistence object from the DAO
        User user = userDao.selectById(id);
        
        if (user == null) {
            // Business-level exception handling
            throw new BusinessException("User not found");
        }
        
        // Object Transformation: Convert DO (Data Object) to VO (View Object)
        return UserConverter.toVO(user);
    }
}

3. Data Access Layer

The DAO provides a clean interface for database operations, hiding the underlying SQL or ORM logic.

@Mapper
public interface UserDao {
    User selectById(Long id);
}

4. Data Storage Layer

The Data Access layer ultimately triggers a command such as SELECT * FROM user WHERE id = ?, which the database executes to retrieve the record.

The full lifecycle: UserController → UserService → UserDao → Database. Upon completion, the data flows back up the chain, undergoing transformation at the Service layer to ensure the Presentation layer receives only the necessary information.

Best Practices for Multi-Layer Calling

1. Enforce Unidirectional Dependencies

To maintain a clean architecture, a layer should only ever be aware of the layer immediately below it.

  • No Layer Skipping: A Controller should never inject a DAO. This prevents business logic from being bypassed and ensures that rules are centralized in the Service layer.
  • No Upward Awareness: The Data Access layer should have no knowledge of the Presentation layer. For instance, a DAO should never handle HTTP status codes or web-related logic.

2. Implement Model Isolation

One of the most common mistakes is using a single object (like a database entity) throughout the entire application. Instead, use specialized models to decouple your layers:

  • DTO (Data Transfer Object): Used for transferring data between services or exposing data via APIs.
  • DO (Data Object / Entity): Represents the structure of the database table and is used strictly within the DAL and Service layers.
  • VO (View Object): Tailored specifically for the frontend/client, containing only the fields required for the UI.

While this requires additional "mapping" code, it prevents changes in the database schema from automatically breaking your public API.

3. Centralize Transaction Control in the Service Layer

Transactions should be managed at the Service layer. Since a single business operation might involve multiple database calls, the @Transactional boundary must encompass the entire service method to ensure atomicity. The Data Access layer should remain "transaction-unaware," focusing solely on executing individual data operations.

4. Standardize Exception Handling

A robust system handles errors gracefully across layers:

  • The DAO layer should throw low-level persistence exceptions (e.g., SQLException).
  • The Service layer should catch these and wrap them into meaningful Business Exceptions (e.g., InsufficientFundsException).
  • The Controller layer (or a global exception handler) should catch these business exceptions and convert them into standardized, user-friendly API responses.

5. Program to Interfaces

Always define Service and DAO as interfaces rather than concrete classes. This promotes the principle of Dependency Inversion, making it significantly easier to swap implementations (e.g., switching from a MySQL DAO to a MongoDB DAO) and allowing for seamless unit testing using Mock objects.

Common Anti-Patterns to Avoid

  • The "God Service": Creating a single, massive Service class that handles every possible business rule. This leads to unmaintainable code. Instead, split services by business domain or sub-module.
  • Circular Dependencies: When Service A depends on Service B, and Service B depends back on Service A. This indicates poor design; resolve it by extracting shared logic into a third component or using an event-driven approach.
  • Map-based Parameter Passing: Passing data through layers using Map<String, Object> instead of strongly typed objects. This destroys type safety, makes the code difficult to navigate, and hides the data contract.
  • Leaky Abstractions: Allowing database-specific logic or exceptions to "leak" into the Controller. If your Controller is catching SQLException, your layers are improperly coupled.

Summary

The core value of a four-layer architecture lies in the separation of concerns and unidirectional dependency. By ensuring that the call chain flows strictly from top to bottom, isolating object models (DTO/DO/VO), centralizing transactions in the Service layer, and standardizing exception handling, you create a system that is resilient to change. Following these principles ensures that as your application scales, it remains organized, testable, and easy to maintain.