How to handle UseCase Interactor constructors that

Question

Using DDD w/ Clean Architecture, I'm instantiating all of my dependencies (e.g. Repositories and Services) first and injecting them into my UseCases. What I've noticed over time is that my list of dependencies for each UseCase has grown quite large over time. For example, my UseCase uses 3 Aggregate Roots so I have 3 repositories. Not so bad. But, as I add more features, I find myself adding Domain Services or more Repositories and having to inject them into the UseCase Constructor as well. Is it ok to have 10+ parameters in a UseCase Interactor? I've always thought having more than 2-3 parameters is a code smell. Is there a better way to handle this? Thank you in advance.

Answer 1

Having to many dependencies in constructor is definitely code smell. It's not very easy to handle it and often time it's more matter of experience and skills, but basically you need to look at your system from different perspective and check whether some services/aggregates can be substituted (merged) by new one, which is dependent on your old ones. Than this new one can eventually prove useful also in other places in your system, so you will reduce your code duplicity. You must just follow SRP.

You can find nice example here: http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/