DDD (领域驱动设计)

DDD（领域驱动设计）教程导读

文集简介：这本教程把领域驱动设计（Domain-Driven Design，DDD）讲成一场贯穿始终的"边界谈判"——业务专家和技术团队坐在一起，谈清楚每个词归谁管、每条规则写在哪、每次变更找谁。全册跟随一家虚构电商公司"青柚商城"的订单域，从第一次事件风暴工作坊走到代码上线后的排错现场，把战略设计、战术设计、架构模式与落地路线逐章铺开。

"这个东西不复杂，就是个下单。"——如果你在需求评审会上听过这句话，或者在周报里写过"对齐一下口径"，那么你已经站在 DDD 的门口了。工程师嘴里的"对齐"，多数时候不是对齐认知，而是各说各话之后勉强达成的临时停火协议。产品说"订单"，指的是用户购物车里结算出来的那张小票；财务说"订单"，指一笔该收款的账；仓储说"订单"，是一张要拣货发货的作业单。三个词共用一个名字，三套规则各写一份代码，然后所有人都惊讶：为什么改一个优惠逻辑，三个系统都得动？

DDD 就是从这类现场长出来的方法论。2003 年 Eric Evans 写下《Domain-Driven Design》时，针对的正是这种"软件越做越大、业务词越说越乱"的局面。他的核心主张不复杂：软件复杂度的最大来源不是技术，而是业务本身；对付它，靠的不是更花哨的框架，而是和懂业务的人一起，把领域知识锻造成一套模型，再让这套模型直接长在代码里。 这句话听起来朴素，真做起来却步步都是谈判——词的归属要谈，规则的存放位置要谈，系统之间的协作方式要谈，连"什么时候允许不一致"都要谈。这本教程就把这些谈判一件件摊开给你看。

全册主线：青柚商城的订单域

为了让方法落地，全册虚构了一家电商公司青柚商城，跟着它的订单域走一遍完整的 DDD 历程。它是初创团队，第一版系统用典型的事务脚本写法堆出来的：Controller 里写业务、Service 里写流程、SQL 里藏规则。前半年跑得飞快，大促之后开始偿还技术债——一个"满减和优惠券能不能叠加"的规则散落在四个地方，营销、交易、财务三拨人各改各的。团队于是开始尝试事件风暴、划分限界上下文、重构聚合，一路踩坑也一路修正。每一章的故事都发生在这个具体的系统上，你看到的每段代码、每张图，都是这场谈判桌上的真实产物。

各章地图与学习路线

第 1 章·为什么需要 DDD：从复杂性的三重来源讲起，说明为什么事务脚本和贫血模型在业务变复杂后会失守；给出一份适用性评估清单，帮你判断自己的项目该不该用 DDD。这是全册的动机章。

第 2 章·战略设计：谈判的第一战场。通用语言怎么建立、又为什么会失守（附一次排错实录）；限界上下文为什么是"语义的主权边界"；核心域、支撑域、通用域怎么划分；上下文之间的七种协作模式与防腐层怎么搭。先学战略设计再学战术设计，因为边界划错，后面的代码写得再漂亮也是白费。

第 3 章·战术设计：边界谈妥之后，把业务规则写进代码。实体与值对象、领域服务与工厂、仓库与领域事件、模块与包结构，最后是一节聚合边界划分练习——用青柚商城的真实争议（订单到底该不该包住库存扣减）带你亲手把聚合拆对。

第 4 章·架构模式与落地：分层架构怎么演进、依赖倒置怎么让领域层摆脱框架绑架、整洁架构的同心圆意味着什么，以及 DDD 与微服务结合时的拆分策略与常见误拆。

第 5 章·建模协作与复盘：事件风暴工作坊的完整流程实录；模型驱动设计的正确打开方式；最后用一整节复盘青柚商城订单域从事件风暴到上线的全过程——背景、操作、结果、解读、变式，一个不少。

第 6 章·高级主题：CQRS 让读写各走各的路，事件溯源把"状态"换成"事实"，遗留系统用绞杀者模式慢慢接管，跨上下文的一致性用 Saga 与最终一致来兜底。这四章是进阶内容，建议在前面章节消化后再读。

第 7 章·实践路线与误区：一张从试点到常态化的落地路线图，加上一份从真实项目里攒出来的误区清单——照着踩坑，不如照着避坑。

这本教程怎么用

如果你是刚接手复杂业务的开发者，按章节顺序读即可，第 2、3 章是重心；如果你是正在推动 DDD 落地的技术负责人，可以直接看第 1 章的适用性评估、第 5 章的全程复盘和第 7 章的路线图，拿着它们去开你的第一次立项会；如果你想快速查某个模式（比如防腐层、Saga），每章开头的支柱页都给出了本章知识地图，可按图索骥。

全册配有大量图示与可运行的代码示例，代码以 Java 和 TypeScript 为主，不依赖特定框架——DDD 是设计方法，不是某个框架的使用说明。读完之后，你应该能独立主持一次事件风暴、划出一份站得住脚的上下文地图、写出一个边界清晰的聚合，并且知道下一次"口径不对齐"的争吵，该把哪句话谈在前面。