domain-driven-design - DDD 与 N 层(3 层)架构

标签 domain-driven-design data-access-layer n-tier-architecture

我已经使用 4 个不同的层来练习 DDD 了一段时间:领域、表示、应用程序和基础设施。最近,我向我的一个 friend 介绍了 DDD 概念,他认为它引入了不必要的复杂层(特别针对接口(interface)和 IoC)。通常,在这一点上,我会解释 DDD 的好处——尤其是它的模块化。所有繁重的工作和引擎盖下的东西都在基础设施中,如果我想彻底改变底层的数据访问方法,我只需接触基础设施层存储库就可以做到。

我 friend 的论点是他可以用同样的方式构建一个三层的应用程序:

  • 商务
  • 资料
  • 介绍

  • 他将创建业务模型(如领域模型)并让数据层中的存储库返回这些业务模型。然后他会调用业务层,也就是数据层。我告诉他这种方法的问题在于它是不可测试的。当然,你可以编写集成测试,但你不能编写真正的单元测试。你能看到他提出的 3 层方法的任何其他问题吗(我知道有,因为为什么 DDD 会存在其他问题?)。

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

    最佳答案

    我想你是在比较苹果和橘子。 N-Tier 并没有禁止它使用接口(interface)和 DI 来轻松进行单元测试。同样,DDD 可以使用静态类和硬依赖来完成。

    此外,如果他正在实现业务对象并使用 Repositories,听起来他正在做 DDD,而您只是在争论语义。

    您确定问题不仅仅是使用 DI/IoC 吗?

    关于domain-driven-design - DDD 与 N 层(3 层)架构,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3833920/

    相关文章:

    php - 一个人修改的小网站,PHP序列化存储数据好吗

    grails - 如何在多个 Grails 应用程序之间共享数据访问层(服务和域类)

    asp.net - 将单元测试慢慢集成到项目中所需采取的步骤

    database - 数据库与代码中的业务逻辑?

    c# - DAL 和 BLL 应该通过的类型

    domain-driven-design - DDD 跨有界上下文引用子实体

    sql-server - 表中没有访问权限时的存储过程访问

    c# - 使用 Entity Framework 从集合中删除项目

    domain-driven-design - 与服务层或域对象本身的接口(interface)? (DDD)

    domain-driven-design - DDD 总体性能