DDD早在2004年就由埃里克·埃文斯提出，但一直处于不温不火的状态，直到微服务盛行之后，DDD再次回到人们视野之中。京东、美团、华为等巨头也都在自家架构中实践了DDD。

DDD究竟有什么优势？它是如何落地的？实施难点又在哪里？结合惟客数据实践DDD的经验，今天就来一起探讨下。

咱们先从一个场景说起。

通常在研发流程中，需求评审完毕后就交由某个研发做设计，方案的设计完全取决于某个人的经验和对依赖模块的熟悉程度，可能很难识别出模块设计上的不合理。即使可以识别出，往往都会以技术的语言和产品经理进行沟通，产品经理可能很难理解，最终难达到预期的目的。

以惟客服务过的某地产集团案例为例。客户的诉求是实现“转赠功能”，比如用户A下单5件商品，将其中2件转赠给用户B，此时用户B的“我的订单”栏会出现一笔含有2件商品的订单，且不可退款的同时，用户B还可以再次实行转赠。

这意味着需要在订单领域生成一种“特殊的订单”和“特殊的拆单”，该订单仅能使用且不能退款。

需求评审完后，产品、研发一起开始做“领域建模”，由于涉及订单领域，也对照之前的“订单模型图”做了方案的设计，发现订单域承载更多的是交易相关，把转赠业务耦合进来，十分困难。

但研发在模型图里发现了专门承载履约的“核销聚合根”，只要核销权限能转出去，就可以满足业务场景，产品经理也十分认可，最终将产品做了修改，将原先的订单转送，变为了履约权限的转赠。

在上面的案例中，无论从产品设计角度，还是转赠场景和交易场景，划分都更清晰；从代码设计角度，减少冲击到订单域，避免现实中独立的两块业务在系统中耦合成一个模块，从而造成订单的核心代码被冲击，后续难维护的后果。最终实现了“多赢”的局面。

这种“多赢”的局面，就取决于DDD过程中带给我们的几点改变：

1、领域模型设计一定程度上拉齐了团队的设计水平，不再取决于某几个人的“经验”。

2、产品、研发建模的过程中，深究业务场景，推导出技术设计的同时也回补了需求漏洞。

3、团队内统一语言，尤其是产品和研发之间，沟通成本低，减少了由于理解差异导致的风险。

4、原先依赖的模块，也采用了DDD的设计，有完整的模型文档，并且有效识别出来了“订单聚合”、“核销聚合”，才使得转赠模块在做设计有了很好的基础。

基于对以上场景的了解，我们再回归定义，从定义出发，一步步拆解。

概念理解：DDD是什么？

DDD全称是领域驱动设计，这里的“领域”可以理解为业务边界，以及指定范围内待解决的业务问题。因此DDD它不是一种架构，而是一套思想，是一种拆解业务、划分业务、确定业务边界的方法。

DDD可以通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，帮助我们设计出清晰的领域和边界，并使得系统具有更好的扩展性，很好的实现技术架构的演进，应对纷繁多变的现实业务问题。

DDD的优势在哪里？

程序员擅长从技术角度来解决项目问题。但一个软件系统是否真正可用，需要通过其提供的业务价值来体现。因此在关注技术的同时，DDD更强调将关注点转向软件系统所提供的业务价值。

我们先回顾下产研团队的协作模式，通常是将一个产品开发上线的各个过程拆出来，由市场/运营、产品、UI交互、前端、后端、测试等角色来做分工，每个过程专人负责。

这么做的好处是标准流水线作业，个体生产效率比较高，但坏处是大家都盯着眼前的一亩三分地，自然很容易忽略整体，更难从整体业务价值出发。同时也容易出现信息不对称的问题，比如产品在讨论A时，前端以为是说B。

那么，根据惟客数据在核心产品“惟客云”中实践DDD的经验总结，其优势可以包含以下几点：

统一语言：领域专家、产品、技术、测试等人员都在一起进行事件风暴（整理出相关联的业务指令和事件），在同一个场景下使用统一语言进行领域模型构建，信息传递不会丢失。

提高效率：设计就是代码、代码就是设计，可以根据领域模型图对编辑进行翻译，即使是新人接手也能快速理解整个业务和代码，上手就能写。

边界清晰：战略设计帮助产品决策人理解哪些投入是最重要的、哪些既有软件资产是可以重新拿来使用的、哪些人应该被加入团队中？战术设计则帮助产品研发人员具体实施。

降低成本：先划分业务边界，确认核心业务，避免伴随功能迭代后的代码不断叠加，导致代码耦合，降低维护成本。

以降低成本为例，假设我们要做一个电商订单下单需求，涉及到用户选定商品，下订单、支付订单、对用户下单时的订单发货：

常见做法是在分析好业务需求之后，开始设计表结构，订单表、支付表、商品表等等，然后编写业务逻辑当功能迭代，订单支付后要支持取消，下单商品要支持退换货，就又需要加表，并针对实现的逻辑不断进行修改。这也意味着当功能不断迭代，代码也会层层上叠。

而DDD要求先划分业务边界。该场景下的核心是订单，那么订单就是业务领域里的聚合逻辑体现。支付、商品信息、地址等等都是围绕订单实体。订单本身的属性决定之后，类似于地址只是一个属性的体现。当你将订单的领域模型构建好之后，衍生了仓库的上下文。

总结来说，DDD优势在质量、效率、成本3方面都得到了体现。

惟客是如何实践DDD的？

从时间线来说，可以分为3个阶段：

2020年7月，引入DDD，在小项目和模块进行试点；

2021年6月，完成在大会员模块进行实践和应用；

2022年3月，完成公司交易、营销、会员、家装产品线的改造和重构。

重点以3月份的项目为例。惟客投入70人参与本次项目，目的是解决老旧项目之间耦合严重、业务边界不清晰、代码重复率高、维护成本高等问题。从落地步骤来拆，包括5个部分：

需求评审

1、过需求、了解相关联业务的用户故事

2、产品输出用户故事地图、原型图、流程图，开发理解相关资料

拆用户故事

1、对照用户故事地图将用户故事进行细分

2、整理出相关联的业务指令和事件（事件风暴）

3、用户故事评审，确保需求没遗漏、业务指令和事件划分正确

领域模型图设计

1、识别应用上下文，划分领域界限（核心、通用、支领域），拆分成多个子域

2、根据用户故事及业务指令区分出查询模型和命令模型

3、在领域内绘制出相关联业务的领域模型图（包含查询模型、聚合、聚合内聚合根、实体、值对象的关系、实体具有的能力、领域服务、领域事件）

4、领域模型图评审

代码实现

1、对照领域模型图建业务指令、事件、实体、值对象、实体能力及领域服务

2、完成领域模块开发，建db入库

3、代码评审，对照领域模型图

4、完成所有业务开发

单元测试

1、对于聚合能力的单元测试

2、领域服务，指令的单元测试

实践过程中遇到哪些问题

为创建通用语言腾出来的时间和精力

通用语言是指非技术岗位也能很容易理解的语言，在目标拉齐的基础上，需要拉齐各个角色对术语都使用统一名词，对业务价值以及规则的描述使用统一的描述方式和规则，并且需要使得每一个人都能听的懂。

以商品条形码为例：

领域专家：从场景角度分析，它主要是供小程序扫描这个条形码进行购买商品

产品：从规则角度分析，商品编码，长度是多少位，组成规则是什么。

开发：按照功能事项的角度去分析，barcode，商品的sku级别的唯一标识，存储方式是什么。

很明显，大家分析问题的角度不一样，给出的语言不同，但本质上商品条形码=商品编码=barCode，因此需要花时间拉齐不同角色间的语言。

领域专家对于实践DDD很重要，但这个角色通常是业务专家，他们工作繁忙、时间难约，较难持续在一个项目中消耗太多时间。

因此在落地中，建议尽可能一次性把业务相关的疑问和问题准备好，减少对接次数、提高效率。

由过程编码 -> 面向对象编码

由数据模型 -> 领域模型

领域模型关注的是领域本身，是业务领域的核心实体，体现在问题域关键概念和之间的联系。构建领域模型的目标是看模型能否清晰表达业务语义、模型能否显性化，扩展性是其次。

数据模型关注的是数据存储，在我们所有的业务中都离不开数据，离不开对数据的CRUD。构建数据模型目标是看扩展性、性能等非功能属性，业务语义的表达则是其次。

人最难转变的是思维惯性，而不是技术和策略本身。因此在实践前，对以上3点有心理预期，并提前做好应对方案，可以更快地落地DDD。

总之，如果企业希望能更好地发挥软件系统的业务价值，从长期价值主义出发，提高代码的可维护性、可扩展性，那么DDD绝对是一套值得尝试的方法