Jos*_*ker 5 domain-driven-design data-access-layer n-tier-architecture
我已经练习了DDD一段时间了4个不同的层:域,演示,应用程序和基础设施.最近,我向我的朋友介绍了DDD概念,他认为它引入了一个不必要的复杂层(特别是针对接口和IoC).通常,在这一点上,我解释了DDD的好处 - 特别是它的模块性.所有繁重的工作都在基础设施中,如果我想彻底改变基础数据访问方法,我只需触摸基础设施层存储库即可.
我朋友的论点是他可以用同样的方式构建一个三层应用程序:
他将创建业务模型(如域模型)并使数据层中的存储库返回这些业务模型.然后他会调用称为数据层的业务层.我告诉他这种方法的问题在于它不可测试.当然,您可以编写集成测试,但是您无法编写真正的单元测试.你能否看到他提出的3层方法的任何其他问题(我知道有,因为为什么DDD会存在？).
编辑:他没有使用IoC.他的例子中的每一层都相互依赖.
que*_*rin 10
我想你在比较苹果和橘子.N-Tier没有任何东西禁止它使用接口和DI以便轻松进行单元测试.同样,DDD可以使用静态类和硬依赖项来完成.
此外,如果他正在实现业务对象并使用存储库,这听起来像是在做DDD,而且你只是在语义上狡辩.
您确定问题不仅仅是过度使用DI/IoC吗？
我想你正在混合一些方法论.DDD是域驱动的开发,旨在使业务域成为您的代码的一部分.您所描述的内容听起来更像是洋葱架构(链接)与"普通"3层方法.使用带有DDD的3层架构没有任何问题.DDD取决于TDD(TestDriven Developement).接口有助于TDD,因为更容易单独测试每个类.如果使用依赖注入(和IoC),则可以进一步减轻它.
洋葱架构是关于使域(又称业务规则)独立于其他一切 - 即.它是应用程序的核心,一切都取决于业务对象和规则,而与基础架构,UI等相关的东西都在外层.这个想法是,模块越接近"洋葱的外壳" - 交换新实施就越容易.
希望这有点清楚 - 现在进行一次小编辑!