Use Case Interactors

The software in the use cases layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case. We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. The use cases layer is isolated from such concerns. We do, however, expect that changes to the operation of the application will affect the use cases and, therefore, the software in this layer. If the details of a use case change, then some code in this layer will certainly be affected.

©Robert C. Martin

Use cases represent a key layer where application-specific business rules are defined and implemented. This layer is critical as it acts as a mediator between the innermost layers of the architecture (Entities) and the outer layers that interact directly with frameworks, databases, and interfaces (like web or mobile UI). Use cases in Clean Architecture orchestrate how data flows into the system from external inputs, how it is processed according to business rules, and then how the outcomes are delivered back to the external interfaces or further outward.

Characteristics of Use Cases in Clean Architecture

  1. Contains Application-Specific Business Rules: Use cases encapsulate the application-specific rules, which describe how business processes are carried out in the system. These rules are distinct from the more general, enterprise-wide business rules encapsulated in Entities. For example, the process of a user placing an order on an e-commerce site would be a typical use case.

  2. Orchestrates Data Flow: Use cases control the flow of data throughout the application, starting from external inputs, through business processing, and back out as a response or result. They coordinate between the domain layer (entities) and the infrastructure or framework layers like databases and UIs.

  3. Boundary between Domain and Infrastructure: In the layered architecture of Clean Architecture, the use case layer acts as a boundary between the domain model (entities) and the more volatile external layers that deal with technology-specific implementations, such as user interfaces and data persistence mechanisms.

  4. Independent from External Concerns: While use cases handle input from and provide output to external agencies (like UI), they themselves remain independent of these external concerns. This independence is achieved by channeling data between layers through well-defined interfaces (data transfer objects or DTOs) and using abstract constructs like ports and adapters.

Use cases in Clean Architecture are central to managing and implementing the application's business logic in a structured, maintainable, and scalable way. By isolating these processes from direct dependencies on external frameworks and databases, the system achieves a clean separation of concerns, aiding in robustness and reducing the impact of changes in external technologies.

Project Structure

Dependency Graph