在领域驱动设计中，领域层被称为不依赖于其他层，即存储库接口位于领域层内，而其实现位于基础架构层。
但是，有界上下文（具有域 + 基础设施）被部署为一个单元（可部署），因此这些层实际上是逻辑而不是物理。那么在域层和基础设施层之间绘制这种虚拟分隔符有什么好处呢？
更新
在传统的分层方法中，域（服务）被称为依赖于基础设施层。相反，当涉及到 DDD / Clean / Hexagonal 架构时，域独立于其他层，因为域层具有由基础设施层实现的接口。
无论您使用 DDD 还是传统的分层方法，您仍然必须模拟存储库，这意味着域实际上并不是独立的。这是正确的吗？
【问题讨论】：
标签： architecture domain-driven-design inversion-of-control 3-tier decoupling
最大的驱动力是允许不同的层在不相互影响的情况下改变。例如，我经常独立于基础设施层测试我的领域层。我通过模拟我的 DAO 和存储库来做到这一点，这可以让我的测试运行得更快，并使它们变得不那么脆弱。
当我的存储库最终需要一个新的实现（Oracle vs MS SQL vs Web Service）时，我也使用过它。当后端服务发生变化时，您不必重写整个应用程序，从而大大降低了您的复杂性。
最后，拆分这有助于您完成SRP。将您的数据库层集成到您的域层往往允许您跳过这一点（至少根据我的经验）。它不会强迫你这样做，但它肯定会鼓励不良行为。
这与我们不在 UI 中编写域逻辑的原因相同。对于任何足够小的例子，这都是浪费时间。只有当您拥有大型、复杂的应用程序时，它的价值才会显现出来。
【讨论】：
Domain Model pattern 背后的假设是域模型要么是应用程序中最复杂的部分，要么是比其他部分更频繁地更改的部分。
领域模型模式试图通过使领域模型独立于其他关注点来解决这个问题。这样做的好处之一是您可以单元测试域模型，使其独立于其依赖项。您还可以更改域模型，而无需更改应用程序的其他部分。
这些是主要优点，但也有缺点。解耦会使代码库更难导航，并且往往需要在层之间进行大量映射。是否this is worthwhile 取决于具体情况（领域模型有多复杂，您还有哪些其他验证替代方案等）
【讨论】：