1

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?
  • 1
    examples always help – Ewan Jan 2 at 16:20
4

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.

  • Thank you for that. This behaviour is clearly a Business logic in my case. I've used another Entity that represents that behaviour and does the orchestration. It was counter-intuitive for me to keep behaviour as Entity because I've wrongly assumed that behaviour must be a Use Case. – grzegorz.kosciolek Jan 4 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.