In his post about Clean Architecture, Robert Martin highlights use cases (or interactors) as a key element of application architecture. He describes the purpose of use cases as follows:
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.
While the description might not be immediately clear, the main idea is evident: we receive data and pass it to domain entities.
Here is another quote, from Eric Evans’ book Domain-Driven Design:
Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
This quote describes the Application Layer, which performs functions similar to the use cases layer. This layer coordinates the interaction of domain objects or entities. Indeed, repository calls and entity creation must occur somewhere. Additionally, interaction with external services and systems is necessary. Accessing them directly from domain objects is ill-advised, as it violates the purity of the domain model.
Thus, the application layer (or use cases) receives an external request, passes parameters to domain entities, and returns the result. It also retrieves entities from repositories, initiates state persistence, and manages interactions with other services and adapters.
Use Cases vs Application Services
There are essentially two options for implementing the application layer and use cases:
- Implementing each use case as a separate class (Interactor).
- Implementing a set of use cases as methods of an application service class (Application Service).
Each approach has its advantages and disadvantages, which I won’t detail here. I prefer the second option because it is less verbose and more explicit from an OOP perspective: performing an action simply means calling a method of a class. Furthermore, you can always create an application service with a single method if needed.