我有一个关于 DDD 分层架构的依赖关系的问题。如果 Repository 实现在基础设施层，这意味着基础设施层依赖于领域层，因为在 Repository 实现中将引用实体。
另一方面，如果在域中使用基础设施服务，则域层可以引用基础设施层。
这不会创建循环引用吗？
【问题讨论】：
标签： domain-driven-design ddd-repositories
在你的情况下是的。我也有同样的问题:)
这是我的解释：
在 eric evans 的架构图中，基础设施层似乎是一个特殊的层。它实现了接口、应用程序、域。
这个有点牵强.....
但另一方面，您可以将基础架构拆分为单独的适配器模块，因为基础架构组件通常由适配器、转换器和外观组成。
例如，
1) 如果您将 MailManager 注入到 DomainService，Domain 可能依赖于邮件。 2）持久化对Domain有依赖（Repository案例）。
但是如果你把邮件和持久化分成两个模块，它们之间就没有依赖关系了。我认为这可能会缓解这个问题。
毕竟，分层是一种解耦组件的方法，而不是目的。
最后但并非最不重要的一点是，我希望得到更令人信服的答案:)
【讨论】：
查看onion architecture，它显示了 DDD 解决方案的良好设置。 （看看我下面的评论 - 如果可以的话，请使用垂直切片 - 使用多年后洋葱的成本似乎不合理）
基本上所有领域服务的领域模型和接口都被认为是核心。层仅依赖于它们上方更靠近核心的层。它们的实际实现由基础设施处理。
域项目不应引用基础设施项目。如果域需要使用某些东西，则应将其定义为域内的接口并在基础架构项目中实现。
最终，您的界面决定了您的应用程序。如何实现的逻辑是外部化的。因此，我希望您拥有包含域模型和域服务的程序集、前端（例如 MVC 等），然后是实现 NHibernate 之类的基础设施程序集以提供数据等。
您可以在链接文章的各个部分中看到实现架构的各种示例。最简单的是here
可以查看相关问题here
主要的好处是，最常发生变化的主要是基础设施问题。新的数据层技术、新的文件存储等。此外，您的核心域应该是相当稳定的，因为它没有实现任何只是通过合约（接口）定义它需要的东西。通过将实现问题放在一个位置，您可以最大限度地减少整个程序集所需的更改量。
【讨论】：