DDD与N-Tier（3层）架构

Question

我已经练习了DDD一段时间了4个不同的层：域，演示，应用和基础设施。最近，我向我的朋友介绍了DDD概念，他认为它引入了一个不必要的复杂层（特别是针对接口和IoC）。通常，在这一点上，我解释了DDD的好处 - 特别是它的模块性。所有繁重的工作都在基础设施中，如果我想彻底改变基础数据访问方法，我只需触摸基础设施层存储库即可。

我朋友的论点是，他可以用同样的方式构建一个三层应用程序：

• 商业
• 数据
• 演示

他将创建业务模型（如域模型）并使数据层中的存储库返回这些业务模型。然后他会调用称为数据层的业务层。我告诉他这种方法的问题在于它不可测试。当然，您可以编写集成测试，但是您无法编写真正的单元测试。你能否看到他提出的3层方法存在任何其他问题（我知道有，但为什么DDD会存在呢？）。

编辑：他没有使用IoC。他的例子中的每一层都相互依赖。

Answer 1

我认为你在比较苹果和橘子。 N-Tier的任何内容都禁止它使用接口和放大器。 DI，以便轻松进行单元测试。同样，DDD可以使用静态类和硬依赖项来完成。

此外，如果他正在实现业务对象并使用存储库，那么听起来他正在做DDD，并且你只是在语义上狡辩。

您确定问题不仅仅是过度使用DI / IoC吗？

Answer 2

我认为你正在混合一些方法。 DDD是域驱动的开发，旨在使业务域成为您的代码的一部分。您所描述的内容听起来更像是洋葱架构（link）与“普通”3层方法。使用带有DDD的3层架构没有任何问题。 DDD取决于TDD（TestDriven Developement）。接口有助于TDD，因为更容易单独测试每个类。如果使用依赖注入（和IoC），则可以进一步减轻它。

洋葱架构是关于使域（a.k.a.业务规则）独立于其他一切 - 即。它是应用程序的核心，一切都取决于业务对象和规则，而与基础架构，UI等相关的东西都在外层。我们的想法是，越接近“洋葱的外壳”模块就越容易交换新的实现。

希望这有点清楚 - 现在进行一次小编辑！

Answer 3

N 层或本例中的 3 层架构与单元测试配合得很好。 您所要做的就是使用依赖注入和存储库模式的 IoC（控制反转）。

业务层可以通过返回所需的确切数据来验证和准备返回的数据用于表示\web api 层。 然后，您可以在单元测试中一直使用模拟层。 您所有的业务逻辑和需求都可以在 bl 层上。并且 Dal 层将包含从更高级别注入的存储库。