I have been pondering the same thing and after finding very little on the subject, I have come to the conclusion “Yes” it is probably the best option.
my reasoning as follows:
- Single Responsibility: If you can’t aggregate use-cases, then each can’t really be single responsibility. Without aggregation, it means domain logic ends up in the presentation layer, defeating the purpose.
- DRY: use cases can be shared, and should be where it makes sense. As long as the intent of the use case is identical. Obviously this should be thought through before being done. In my experience there’s rarely a need for this outside of the next point.
- Orchestrator classes: for instance if you need to fetch multiple data sources and persist to a repository. A use case which will run all of those child use cases is required, ensuring things like order of operations and concurrency are correctly implemented. This I think is the most compelling reason for calling other use cases.
To preserve single responsibility, I would consider limiting aggregating use-cases to do only that, i.e. executing those use cases and doing any final transformations.
Given the age of this question, I’d be interested to know which way you went with this and issues you encountered.