如何处理DDD /中具有太多依赖参数的UseCase交互器构造函数？

Question

使用DDD / Clean，我首先实例化我的所有依赖项(例如存储库和服务)，并将它们注入到我的UseCases中。随着时间的推移，我注意到的是，随着时间的推移，我对每个UseCase的依赖列表已经变得相当大。例如，我的UseCase使用3个聚合根，所以我有3个存储库。没那么糟。但是，当我添加更多的特性时，我发现自己添加了域服务或更多的存储库，并且不得不将它们注入到UseCase构造器中。在一个10+接口中有UseCase参数可以吗？我一直认为有超过2-3个参数是一种代码气味。有更好的方法来处理这件事吗？提前谢谢你。

Answer 1

构造函数中有许多依赖项，这无疑是代码的味道。处理它并不容易，而且通常时间更多的是经验和技能的问题，但基本上您需要从不同的角度来看待您的系统，并检查一些服务/聚合是否可以被新的服务/聚合所替代(合并)，这取决于您以前的服务/聚合。这个新版本最终也会在您的系统中的其他地方被证明是有用的，因此您将减少代码的欺骗性。你必须跟着SRP。

您可以在这里找到一个很好的例子：http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/