Domain Use Case

Question

In my understanding of Uncle's Bob Clean Architecture, a Use Case (Interactor) is responsible for orchestrating the Entities. At the same time, it represents Application-specific rules. The business rules live in Entities.

I have a need to orchestrate the Entities to achieve a Business-specific rule. What is the best approach for it?

1. Is it allowed to have a Use Case in the Domain layer (rather than in the Application layer) to indicate that this use case is business rules, not application rules?
2. Or should I simply create another Entity that will do the orchestration?

Answer 1

The division of specifications into "Business Rules" and "Application Rules" is always going to be somewhat arbitrary.

In the abstract it might seem obvious that the Sales Report is a Use Case and compiling it in the application requires application level logic to manipulate Orders. Where as an Order is a Entity that contains Business logic.

But you could equally well imagine a business which produces Sales Reports from other people's data and considers the rules for producing them Business Logic and the list of orders merely application input.

You have to look at the specific case and decide what logic is reusable and inherent to the business rather than application specific.