注入依赖层应用程序/域/存储库答案

【问题标题】：Injection Dependencies Layers Application / Domain / Repository注入依赖层应用程序/域/存储库
【发布时间】：2023-03-05 04:14:01
【问题描述】：

在使用 DDD 概念的应用程序中，如果有任何标准，我怀疑谁可以将（依赖项）注入给定类的构造函数。

例如，在 Application、Domain 和 Repository 层之间。

1）需要注入用户的ClientAppService（应用层），我应该注入UserApplicationService并从中调用UserService（域）还是直接在ClientApplicationService中注入UserService？

2) 我应该在 ClientService（域）中注入 UserService 并从中调用 UserRepository 还是可以将 UserRepository 直接注入 ClientService？

如果我要注入对等类，我会担心循环引用。

但我也认为我不应该注入另一个Entity的Repository，因为通常repository的方法在服务中有一个规则，必须事先调用。

有没有人问过这个问题，你平时是怎么处理的？

【问题讨论】：

标签： asp.net dependency-injection architecture domain-driven-design solid-principles

【解决方案1】：

域实体和值对象几乎从不使用构造函数注入。

这是出于关注点分离的目的；领域模型中对象的职责是管理它们自己在内存中的表示。

他们完成工作可能需要的其他功能作为参数传递给他们。

这方面的典型机制是“域服务”，Evans 在蓝皮书的第 5 章中对此进行了描述。

举个例子 - 假设我的订单汇总需要在订单项更改时更新其报价。我可能会传入一个接受 SKU 并返回价格的接口作为参数。就Order 而言，该查找发生在“其他地方”。它不在乎细节。实现可能会加载另一个聚合以查看其当前状态，或向某个远程系统发送消息，或对答案进行硬编码。

域服务实现通常会注入对应用程序或基础架构层提供的功能的依赖项。

【讨论】：

【解决方案2】：

考虑到关注点分离和职责分配，您应该准确地注入您的工件所依赖的内容。这听起来可能有点明显，但它更深入一些。

考虑您的 (2) 示例：

我应该在 ClientService（域）中注入 UserService 并从中调用 UserRepository 还是可以将 UserRepository 直接注入 ClientService？

您可能应该首先问自己您的 ClientService 依赖于哪种能力？

如果它 (ClientService) 关心能够从它 (ClientService) 当前拥有的信息中找到用户，它可能应该直接接收 UserRepository 并能够自行找到用户。
如果它（ClientService）需要一个用户，但它没有找到用户所需的信息（这个信息目前在应用层级别），也许ClientService应该直接接收用户域对象，用直接从应用程序级别使用的存储库。
如果它（ClientService）需要来自 UserService 的某种与域相关的功能作为其操作的一部分，那么，在这种情况下，UserService 可能会直接注入 ClientService。

关于此主题的其他可能讨论可能是您是否真的需要所有这些域服务，如果您最好直接从应用层调用规则丰富的实体/聚合，它可能会使您的整体设计、注入模式和边界更简单。

此外，很多时候，您可能希望为您的工件注入工厂，而不是直接实例化的工厂。

另一点可能是关于：

但我也认为我不应该注入另一个Entity的Repository，因为通常repository的方法在服务中有一个规则，必须事先调用。

这可能表明您的域内部存在一些混乱。存储库的角色应该围绕“从可能的实体的宇宙中找到您的域实体”的路线。从这个意义上说，UserRepository 使您能够从存在于您的 Universe 中的用户中找到用户，因此它应该是一个非常孤立的操作，并且不应该依赖于服务或其他实体。如果用户存在，它应该可以从 UserRepository 中“找到”（并且可以持久化，因为它是双向的）。

在这种情况下，从教条的角度来看，您不应该担心“在 ClientService 中注入 UserRepository”。如果您的客户端服务中的操作需要查找和使用用户实体，您应该这样做。您可能担心的是您的实体/聚合是否设计良好，或者您是否有某种错误的职责可能会引发这种“我不应该将其注入其中”的“感觉”。

【讨论】：