DDD Hexagon - 域层在任何情况下都应该与基础设施 (DAL) 层对话吗？
FBr*_*t87 6 architecture domain-driven-design hexagonal-architecture
据我了解，六边形架构的关键规则之一是域层如何与除与其一起工作的应用程序层之外的所有内容隔离（域层完全没有依赖关系，因为它位于核心）：
那么我的问题是，域层是否做过任何工作或有任何数据持久性方面的知识？假设我们有一些业务逻辑依赖于数据的检索和持久化，那么它是否应该始终由应用程序层来协调？
加载业务逻辑运行所需的所有内容 -> 告诉领域层运行所有业务逻辑 -> 提取业务逻辑的结果并告诉基础设施层保存它们 ->
从这个意义上说，应用程序层不是总是需要跟踪域层计算的任何结果，因此总是会实现某种 UnitOfWork 模式来跟踪这些结果吗？
域层是否可以与存储库或存储库的接口一起使用？有一些消息来源似乎表明这很好，但从我的角度来看，这与图表完全矛盾。
假设我们有一些业务逻辑依赖于数据的检索和持久化，那么它是否应该始终由应用程序层来协调？
在理想化的设置中，您可以清楚地分离关注点：域模型使用本地内存中已有的信息来计算事物，而应用程序代码则协调从本地内存复制信息或向本地内存复制信息。
表达方式略有不同：我们应该能够在不影响域模型实现的情况下替换所有管道。
在简单版本中，我们立即知道本地需要什么信息，因此应用程序可以获取所有内容的副本，域模型计算更改，然后应用程序代码将本地更改复制到需要的位置。
如果我们不一定事先知道我们需要的所有信息，那么这就变得更加棘手。在这些情况下，您最终需要做出选择，是询问域模型需要什么信息，然后获取它，还是将查找信息本身的功能传递给域模型。
您可能不会直接从域模型使用存储库 - 不完全是；您更有可能看到域服务。换句话说，获取某些信息的功能可能具有某种表示形式，您可以将其作为参数传递给域模型，以便它可以执行自己的查询。
注意：在 Evans 的原著中，领域服务是在对领域进行建模时出现的一种模式（第 5 章），而存储库是在生命周期管理中出现的一种模式（第 6 章）。
分布式信息通常涉及故障模式，我们通常不希望我们的域代码被一堆故障管理逻辑弄乱，就像我们通常不希望我们的域代码关心一堆持久性一样的担忧。
也可以看看