What is the flow of control in a clean architecture?

The flow of control in a Clean Architecture is a meticulously designed system that ensures robust, testable, and maintainable software by strictly adhering to the Dependency Rule. This rule dictates that source code dependencies can only point inwards, from outer layers to inner layers.

The Fundamental Principle: The Dependency Rule

At the heart of Clean Architecture's control flow is the Dependency Rule. This rule states that dependencies, whether source code dependencies, compilation dependencies, or deployment dependencies, must always point inwards, towards the higher-level policies. Inner circles contain higher-level policies and business rules, while outer circles contain lower-level details like UI, databases, and external interfaces.

• Unidirectional Dependencies: No code in an inner circle can know anything about code in an outer circle. This means if you have code in an outer layer, it can depend on an inner layer, but an inner layer cannot depend on an outer layer.

Control Flow from Outside to Inside: The Natural Invocation

Control that flows from outside to inside is implemented naturally, as it follows the Dependency Rule. This is the most straightforward aspect of control flow in a Clean Architecture. Outer layers, which encapsulate lower-level details, inherently depend on inner layers, which contain the application's core business logic and policies.

• Direct Calls: An outer layer can directly create an object of a type defined in an inner layer and then call one of its methods. This action perfectly aligns with the Dependency Rule, as the dependency arrow points inwards.

• Example:

  • Consider a WebController (an outer layer, part of the Frameworks & Drivers) that handles an incoming HTTP request.

  • This WebController needs to perform an application-specific task, such as creating a new user.

  • It will instantiate a CreateUserUseCase (an inner layer, part of the Application Business Rules) and then invoke its execute() method.

    // In an outer layer (e.g., Web Frameworks & Drivers)
    class UserController {
    private CreateUserUseCase createUserUseCase;
    
    // Dependency Injection for the use case
    public UserController(CreateUserUseCase useCase) {
        this.createUserUseCase = useCase;
    }
    
    public Response createUser(UserRequest request) {
        // Create input data for the use case
        CreateUserInput input = new CreateUserInput(request.getUsername(), request.getPassword());
    
        // **Control flows naturally from outside (Controller) to inside (Use Case)**
        // A method in an outer layer creates an object of an inner type and calls its method.
        CreateUserOutput output = createUserUseCase.execute(input);
    
        // Handle output and return response
        return new Response(output.getMessage());
    }
    }

Control Flow from Inside to Outside: Inversion of Control

While dependencies strictly point inwards, the logical flow of execution often needs to communicate results back outwards. Since inner layers cannot directly depend on outer layers, this is achieved through Inversion of Control (IoC), typically implemented using interfaces and polymorphism.

• Abstractions and Implementations:
  1. An inner layer (e.g., a Use Case) defines an interface (an abstraction) that represents a service or a presenter it needs.
  2. An outer layer then implements this interface.
  3. The inner layer depends on the interface (which is also an inner artifact), and the outer layer implements it. When the inner layer "calls" the interface method, the control flow is effectively passed back to the outer layer's concrete implementation without violating the Dependency Rule.
• Common Scenarios:
  • Use Cases to Presenters: After a use case finishes its execution, it needs to present the result to the user interface. It achieves this by calling methods on an interface (e.g., UserOutputPort or Presenter) that is implemented by an outer layer (e.g., a WebPresenter).
  • Use Cases to Gateways/Data Access: Use cases interact with data stores via interfaces (e.g., UserRepository) defined in the Entities or Application Business Rules layers. The actual database access logic (e.g., SQLUserRepository) resides in an outer layer (e.g., Frameworks & Drivers) and implements this interface.

Orchestration of Control Flow

The control flow in a Clean Architecture involves a choreographed interaction between layers:

1. Request Reception: An outer layer (e.g., Web/UI) receives an external request or user input.
2. Input Translation: This outer layer translates the raw input into a format suitable for the inner Application Business Rules (e.g., a simple data structure for a Use Case Input Port).
3. Use Case Invocation: The outer layer invokes the appropriate Use Case (inner layer) by passing the translated input. This is the "natural flow" described above.
4. Core Logic Execution: The Use Case executes the application-specific business rules.
5. Data Persistence (via Ports): The Use Case interacts with data storage via interfaces (Ports) defined in inner layers. The actual data access logic (Adapters) resides in outer layers and implements these ports.
6. Output Preparation (via Ports): Once the Use Case completes, it prepares an output and passes it to an output port interface (e.g., a Presenter interface) defined within the inner layers.
7. Output Presentation: An outer layer (the concrete Presenter implementation) receives this output and transforms it into a suitable format for the user (e.g., JSON for a web API, or rendered HTML for a UI).

Summary of Control and Dependency Flow

This bidirectional nature of logical control flow, while maintaining a strict unidirectional dependency rule, is what makes Clean Architecture so powerful for maintaining separation of concerns and enabling independent development and testing of core business logic.