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

一、前言

领导：为什么要使用DDD?

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

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

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

二、开发成本

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

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

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

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

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

QQKpZOJC" style="text-align: center;">

架构模式，开发成本曲线

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

三、架构对比

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

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

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

1. MVC

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

MVC 分层结构

• 以应用层 Service 使用 DAO、PO 基础设施包装业务逻辑的开发方式，乍一看以为应用层是在对领域建模的实现，”领域层“有着丰富的对象链接，和真正的领域模型也非常类似，但当我们代码随着业务功能逻辑的逐步实现中会慢慢发现，我们写了一堆的 get/set 对象，而他们被反复交叉使用，没有与任何领域聚合，也就是不具有任何的行为动作，只是一堆贫血模型对象。
• 这种反模式的设计，其实完全与面向对象的设计是背道而驰的，面向对象的设计更希望行为和数据绑定在一起，与之对比的贫血模型更像是面向过程设计。
• 在 MVC 分层结构下，所有的行为都被写入到 Service 对象中，最终你会得到一组事务处理的过程脚本，从而完美的避开了领域模型设计所带来的好处(清晰的职责边界、聚合的功能服务、清晰的面向对象)。

2. DDD

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

DDD 分层结构

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

四、设计原则

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

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

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

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

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

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

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

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

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

五、举个例子

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

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

1. 工程结构

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

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

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

• Lottery：分布式部署的抽奖服务系统，提供抽奖业务领域功能，以分布式部署的方式提供 RPC 服务。
• Lottery-API：网关API服务，提供;H5 页面抽奖、公众号开发回复消息抽奖。
• Lottery-Front：C端用户系统，vue H5 lucky-canvas 大转盘抽奖界面，讲解 vue 工程创建、引入模块、开发接口、跨域访问和功能实现
• Lottery-ERP：B端运营系统，满足运营人员对于活动的查询、配置、修改、审核等操作。
• DB-Router：分库分表路由组件，开发一个基于 HashMap 核心设计原理，使用哈希散列+扰动函数的方式，把数据散列到多个库表中的组件，并验证使用。
• Lottery-Test：测试验证系统，用于测试验证RPC服务、系统功能调用的测试系统。

2. 流程拆解

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

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

• 拆解功能流程，提炼领域服务，一步步教会你把一个业务功能流程如何拆解为各个职责边界下的领域模块，在通过把开发好的领域服务在应用层进行串联，提供整个服务链路。
• 通过这样的设计和落地思想，以及在把流程化的功能按照面向对象的思路使用设计模式进行设计，让每一步代码都变得清晰易懂，这样实现出来的代码也就更加易于维护和扩展了。
• 所以，你在这个过程中学会的不只是代码开发，还有更多的落地思想实践在这里面体现出来。也能为你以后开发这样的一个项目或者在面试过程中，一些实际复杂场景问题的设计思路，打下不错的基础。