domain-driven-design - 如何处理在 DDD w/Clean Architecture 中具有太多依赖参数的 UseCase Interactor 构造函数？

Question

使用 DDD w/Clean Architecture，我首先实例化我的所有依赖项(例如存储库和服务)并将它们注入(inject)到我的用例中。随着时间的推移，我注意到我的每个用例的依赖项列表随着时间的推移变得非常大。例如，我的用例使用 3 个聚合根，所以我有 3 个存储库。还不错。但是，随着我添加更多功能，我发现自己添加了域服务或更多存储库，并且还必须将它们注入(inject)到用例构造函数中。在 UseCase Interactor 中有 10 个以上的参数可以吗？我一直认为拥有超过 2-3 个参数是一种代码味道。有没有更好的方法来处理这个问题？提前谢谢你。

Answer 1

在构造函数中有很多依赖项绝对是代码味道。处理它不是很容易，而且通常更多的是经验和技能问题，但基本上你需要从不同的角度看待你的系统，并检查一些服务/聚合是否可以被新的服务/聚合所取代(合并)，这是依赖的在你的旧的。比这个新的最终证明在您系统的其他地方也有用，因此您将减少代码的口是心非。您必须只遵循 SRP。

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