DDD Hexagon - 域层在任何情况下都应该与基础设施 (DAL) 层对话吗？

Question

据我了解，六边形架构的关键规则之一是域层如何与除与其一起工作的应用程序层之外的所有内容隔离（域层完全没有依赖关系，因为它位于核心）：

我的问题是，域层是否做过任何工作或有任何数据持久性方面的知识？假设我们有一些业务逻辑依赖于数据的检索和持久化，那么它应该始终是应用层来编排这个吗？

加载业务逻辑运行所需的所有内容 -> 告诉领域层运行所有业务逻辑 -> 提取业务逻辑的结果并告诉基础设施层将它们持久化 ->

从这个意义上说，应用程序层不是总是需要跟踪域层计算出的任何结果，因此总是会实现某种 UnitOfWork 模式来跟踪这些结果吗？

领域层是否可以与存储库或存储库的接口一起使用？有一些消息来源似乎表明这很好，但从我的角度来看，这与图表完全矛盾。

Answer 1

假设我们有一些业务逻辑依赖于数据的检索和持久化，那么它应该始终由应用程序层来编排吗？

在理想化的设置中，您可以清楚地分离关注点：域模型使用本地内存中已有的信息来计算事物，而应用程序代码则协调从/向本地内存复制信息。

表达方式有所不同：我们应该能够在不影响域模型实现的情况下替换所有管道。

在简单版本中，我们立即知道本地需要什么信息，因此应用程序可以获取所有内容的副本，域模型计算更改，然后应用程序代码将本地更改复制到需要的位置。

如果我们不一定事先知道我们需要的所有信息，那就会变得更加棘手。在这些情况下，您最终需要做出选择：询问域模型需要什么信息，然后获取它，或者将“功能”传递给域模型以查找信息本身。 您可能不会直接从域模型使用存储库 - 不完全是；您更有可能看到域服务。换句话说，获取某些信息的能力可能具有某种表示形式，您可以将其作为参数传递给域模型，以便它可以执行自己的查询。

注意：在 Evans 的原著中，领域服务是在对域进行建模时出现的一种模式（第 5 章），而存储库是在生命周期管理中出现的一种模式（第 6 章）。

分布式信息通常涉及故障模式，我们通常不希望我们的域代码被一堆故障管理逻辑弄乱，就像我们通常不希望我们的域代码关心一堆故障管理逻辑一样。持久性问题。

另请参阅

功能核心，命令式外壳
以正确的方式构建协议库
异步注入

Answer 2

这是一个正确的版本，因为六边形之外的部分纯粹是基础设施，不应该在那里保留任何逻辑。