怎么说服领导，能让我用DDD架构？

发布时间：2025-11-05 04:09:16 来源：云智核 作者：数据库

本文转载自微信公众号「bugstack虫洞栈」，说服作者小傅哥。领导转载本文请联系bugstack虫洞栈公众号。架构

一、说服前言

领导：为什么要使用DDD?领导

我也苦思冥想，怎么跟领导说咱们从 MVC 升级到 DDD 吧，架构因为 DDD 代码结构更加清晰、说服领域驱动比测试驱动开发更加先进、领导研发的架构兄弟们也更想用用新框架等。

不过这么聊被喷一顿不说，说服还得说你是领导过度设计瞎折腾，咋回事呢?架构因为没聊到重点呀，你MVC升级DDD;给业务带来了什么、说服提升了交付效率吗、领导降低了公司研发成本吗，架构都没有?不仅没有，你还说为了后期的迭代维护，前期会需要更多的设计和开发时间。咋?你是想这一个Q就把我送走吗，我刚来咱们部门KPI在那悬着，压的我头发都白了!别瞎搞，求稳!

那就不搞了吗?搞哇，不让搞换领导!但搞之前，要考虑清楚，DDD 不是 Silver Bullet，你有一腔热血虽好，可是云南idc服务商也得知晓 DDD 的设计原则是什么、它更适合的场景是什么、与 MVC 对比有什么云泥之别。

二、开发成本

使用 DDD 模式开发代码的成本到底在哪?是因为使用 DDD 四层分层结构就比MVC 三层分层结构 更浪费时间吗?其实并不是，因为四层结构相对于三层结构，反而更好的区分了代码所属职责，在熟悉模块功能职责后，开发起来也会更加顺畅。

那这里的 DDD 领域驱动设计开发的成本在哪呢?这个成本在于对于一个复杂系统又尚未在开发前期就有非常充足的经验来拆分职责边界、划分功能领域、明确编排逻辑和对未知流程扩展的把控上，所带来的风暴模型设计成本。

而通常使用的 MVC 结构基本不会出现这样的问题，因为在实际的代码中，DAO、PO、WordPress模板VO等都是共用的，大家在开发代码的时候，像堆泥球一样面向过程写代码，直接串联出产品的PRD功能节点即可，不用过多的思考解耦和内聚。

那不是可以设计模式吗，这就需要看你是站在哪个维度去思考问题。设计模式在这里是战术问题的，DDD和MVC是确定战略问题的，有点像是说：“方向不对，努力白费一样”

那么现在我们再来看这条开发成本曲线：

架构模式，开发成本曲线

三、架构对比

在了解和掌握 DDD 领域驱动设计的路上，你一定会碰到两个抽象的钉子 —— “贫血模型”、“充血模型”：

贫血模型：事务脚本模式，最早起源于 EJB2，到 Spring 进入开“春”盛世。

充血模型：领域模型模式，2003年提出，一直到《实现领域驱动设计》的问世，才开启了 DDD 的大门。但国内直到微服务、低代码的兴起，才开始 DDD 热

1. MVC

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

MVC 分层结构

2. DDD

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

DDD 分层结构

四、设计原则

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

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

拒绝泥球小单体、拒绝污染功能与服务、拒绝加功能排期一个月

架构出高可用极易符合互联网高速迭代的应用服务

物料化、组装化、可编排的服务，提高人效

要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计

要职能清晰的分层，而不是什么都放的大箩筐

DDD 的领域模型设计，界限内的上下文，可以拆分为独立的微服务。但不仅要从业务视角看问题，也要考虑非业务的技术因素，包括：高性能、安全、团队、技术异构等，这些非业务的技术因素，也会决定领域模型落地的具体落地。

五、举个例子

你说我 MVC 不好，你说我 MVC 贫血模型，PO 类不断的膨胀，但让我用 DDD 又都是理论，程序员更喜欢看的是已经落地的代码，告诉我怎么干。

为什么这么难落地呢?因为从 MVC 过度到 DDD 描述对比只是积累了 MVC 失败的教训，但没有 DDD 成功的经验，所以更多的时候想落地 DDD 除了有理论支撑，更需要一份案例摆在面前。

1. 工程结构

所以为了让更多的码农看到在 DDD 上一条能走的路，专门折腾了个 DDD 分布式抽奖系统，来告诉大家怎么使用 DDD 开发业务需求;

DDD 分布式抽奖系统，工程分布

整体系统架构设计包含了6个工程：

2. 流程拆解

当我们拿到产品的 RPD 以后，并不是直接上手开发，而是需要从流程中拆解出一份面向对象设计的领域服务，举例;

DDD 分布式抽奖系统，流程拆解

相关文章