DDD 六边形架构 - 领域层是否在任何情况下都需要与基础设施层（DAL）通信？

Question

5

据我理解，六边形架构的一个关键规则是将领域层与除了与之协作的应用层以外的所有内容隔离开来（领域层完全没有依赖项，因为它位于核心位置）。

我的问题是，领域层是否会进行任何工作或对数据持久化有任何了解？假设我们有一些业务逻辑依赖于检索和持久化数据，那么这种情况下，应该总是由应用层来协调吗？

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

在这种意义上，应用层是否总是需要跟踪领域层计算出的任何结果，并因此始终实现某种UnitOfWork模式来跟踪这些结果？

领域层是否会使用存储库或存储库接口进行任何工作？有些来源似乎表明这是可以的，但从我的角度来看，这与图表完全矛盾。

- FBryant87

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VoiceOfUnreason · Accepted Answer

假设我们有一些业务逻辑依赖于检索和持久化数据，这应该总是由应用层来协调吗？

在理想的情况下，您拥有清晰的关注点分离：领域模型使用本地内存中已有的信息计算事物，应用代码编排将信息从/到本地内存中复制。

换句话说：我们应该能够替换所有管道而不会干扰领域模型的实现。

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

在那些我们不一定预先知道需要哪些信息的情况下，情况就会变得更加棘手。在这些情况下，您最终要在询问领域模型需要哪些信息后获取它，或者将查找信息本身的能力传递给领域模型之间做出选择。

您可能不会直接从领域模型中使用存储库 - 不完全是这样; 您更有可能看到一个领域服务。换句话说，获取某些信息的能力可能具有一些表示形式，您将其作为参数传递给您的领域模型，以便它可以执行自己的查询，例如。

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

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

另请参见：