DDD：持久性逻辑应该属于基础架构层吗？

Question

我的应用程序遵循DDD设计原则。它是一个ASP.NET MVC应用程序，其中MVC web应用程序是表示层（我将控制器移到了应用层）。它还有应用层，主要是应用服务、用例等。应用层之上是域模型所在的域层。然后是基础结构层，它位于所有其他层之上，并且不依赖于其他层。

但是我注意到一个问题，如果持久化逻辑像DDD书中所说的那样进入基础结构层，基础结构层就会依赖于域层。例如，存储库需要知道要创建的领域模型（实体）的类型，有了这些知识，它们就变得依赖于领域层。然而，最初的DDD原则建议基础结构层应该绝对不依赖于任何东西。

所以现在我很困惑，持久性逻辑真的应该，属于基础架构层吗？如果是这样，它使基础设施层依赖于域层。如果不是，那么它应该在哪里呢？应用层？或者可能是应用程序层和域层之间的一个单独的层（正如应用程序服务使用存储库一样，存储库使用域模型）。你觉得呢？

Answer 1

我认为在这里可能有帮助的一个重要概念是区分依赖的类型--特别地，一个层或组件可以依赖于另一个层，因为：

1. 根据该层中定义的概念定义，或
2. 它使用另一层--通过委托给该层（也称为调用该层中服务的方法）
3. 或以上两者

控制的倒置和依赖注入使这种区分变得更加重要。它们指导我们应该依赖于抽象而不是具体。

最初的DDD书籍没有特别提到这一点，但它已经成为实现DDD系统的一种非常常见的模式。

它也被称为端口和适配器模式，或六边形体系结构。

其思想是，它按照洋葱的“知道”来建模依赖关系--外层知道内层，但内层不知道外层。

这就是国际奥委会介入的地方。因为我们有一个内层委托给一个外层，所以只有外层实现了在一个内层中定义的接口（它之所以能这样做，是因为它知道内层的情况），才有可能。然而，IoC容器注入了实际的具体实现，有效地允许内层将控制权委托给外层，而不依赖于外层。

在这种概念化中，请求从左上角流到右下角，而内层对外层一无所知。