当前位置：首页 > news >正文

DDD（二）对比 MVC 架构，DDD 的优劣势

news 2025/10/23 8:37:06

一、研发成本

使用 DDD 模式开发代码的成本到底在哪？是因为使用 DDD 四层分层结构就比 MVC 三层分层结构更浪费时间吗？

其实并不是，因为四层结构相对于三层结构，反而更好的区分了代码所属职责，在熟悉模块功能职责后，开发起来也会更加顺畅。

那这里的 DDD 领域驱动设计开发的成本在哪呢？

这个成本在于对于一个复杂系统又尚未在开发前期就有非常充足的经验来拆分职责边界、划分功能领域、明确编排逻辑和对未知流程扩展的把控上，所带来的风暴模型设计成本。而通常使用的 MVC 结构基本不会出现这样的问题，因为在实际的代码中，DAO、PO、VO 等都是共同的，大家在开发代码的时候，像堆泥球一样面向过程写代码，直接串联出产品的 PRD 功能节点即可，不用过多的思考解耦和内聚。可能会有同学会问，不是可以使用设计模式吗？这就需要看你是站在哪个维度去思考问题。设计模式在这里确定战术问题的，DDD 和 MVC 是确定战略问题的，有点像是说：“方向不对，努力白费” 一样。

与其它两种分层结构相对比，使用 DDD 的时候，需要在前期投入较多的时间成本来设计领域建模，所以前期成本会更高一些。
但随着业务不断迭代后的逻辑复杂性增加，DDD 系统架构所开发的代码稳定性会更好，也就说明 DDD 更容易扩容和维护。
所以框架结构的更换，不是最终增加开发成本的地方，如果你不做领域建模，也不做更多的设计思考，那么即使是 DDD 的四层架构，也能让你写出 MVC 的效果。而那些对业务场景经验丰富的架构师或研发人员，已经非常明确了各业务功能的职责边界，要实现一个系统需求需要完成哪些核心领域服务，再这种的情况用 DDD 也不会带来多少开发成本，反而更加游刃有余了！这就是为什么说，需要领域专家，因为专家已经积累了很多的战略设计经验。
此外，使用 DDD 领域驱动设计的模式进行开发，除了解决需求的迭代成本，更多的时候是要面对公司战略调整后，系统的交接、人员的更替和新增，都要在原油的工程架构下继续迭代开发，否则就要推翻重新做，那样所面临的更替成本将更大，同时又是开发了一个与人员绑定不易于交接维护的工程代码。

二、架构对比

2.1 MVC 架构

MVC 分层结构将 “状态”（数据，成员对象）、“行为”（逻辑、过程），分离到不同的对象中，只有状态的对象（VO -> Value Object）被称为贫血模型，只有行为的对象，就是框架分层中常见的 Logic/Service/Manager 层（对应到 EJB2 中的 Stateless Session Bean）。

以应用层 Service 使用 DAO、PO 基础设施层包装业务逻辑的开发方式，乍一看以为应用层是在对领域建模的实现，“领域层” 有着丰富的对象链接，和真正的领域模型也非常类似，但当我们代码随着业务功能逻辑的逐步实现中会慢慢发现，我们写了一堆的 get/set 度喜庆，而他们被反复交叉使用，没有与任何领域聚合，也就是不具有任何的行为动作，只是一堆贫血模型对象。

这种反模式的设计，其实完全与面向对象的设计是背道而驰的，面向对象的设计更希望行为和数据绑定在一起，与之对比的贫血模型更像是面向过程设计。

再 MVC 分层结构下，所有的行为都被写入到 Service 对象中，最终你会得到一组事务处理的过程脚本，从而完美的避开了领域模型设计所带来的好处（清晰的职责边界、聚合的功能服务、清晰的面向对象）。

2.2 DDD 架构

DDD 的分层结构也是面向对象编程的本质：“一个对象拥有行为和数据”，在领域包括了：对象、聚合对象、仓储和 Service 实现。

DDD 的分层结构更注重 Domain 领域层的实现，由很薄的应用层定义接口和编排接口，由领域层做具体的实现。
所有的业务逻辑都按照各自的职责边界拆分成一块块的功能领域，米一个功能领域都是充血模型结构的具体实现。
那么这样的代码最终实现以后，无论在迭代、维护、人员更替，都能很好的按照领域设计文档找到对应的代码实现进行开发。

2.3 设计原则

首先，DDD 的设计分为战略和战术：

战略设计：从业务视角出发，建立业务领域模型、划分职责边界，建立通用语言的限界上下文。顶层战略设计构建的领域模型结构，是整个服务后期编排的重点，它确定了功能的职责边界、聚合、对象等，也就绝对了后期服务战术实现的开发和交付质量。重视战略，才能落地好战术！
战术设计：从技术视角出发，侧重于领域模型的技术实现，完成功能开发和交付落地。领域设计的重点包括：实体、聚合对象、值对象、领域服务、仓储，还有一个非常重点的设计模式。任何一个较为复杂的领域模式实现都需要考虑设计模式的使用，否则即使战略优秀，战术也能干回 MVC 去。

在以 DDD 领域驱动设计落地的过程中，要依靠领域驱动设计的设计私信啊个，通过事件风暴建立领域模型，合理划分领域逻辑和无力辩解，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。