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