“订单”这个词我在三个不同团队的系统里见过三种完全不同的定义销售团队说的订单是一份意向确认书履约团队说的订单是一张拣货发货指令财务团队说的订单是一笔应收凭证。三个系统各有一套字段、各有一套状态机接口对接时字段名一样、语义全不一样改一个“订单状态”能让三个团队开三次会。这种场景见得太多了最后大家往往得出同一个结论问题不在代码写得好不好而在于整个组织对“订单”这个词没有共识代码只是把这个分歧忠实地记录了下来。领域驱动设计DDD真正要解决的就是这类由业务复杂度带来的问题——它不是一套分层模板也不是一堆设计模式的拼盘而是一套让业务语言、系统边界和代码模型三者对齐的方法论。这篇笔记整理的是DDD最基础的那层理论与概念通用语言、限界上下文、上下文映射、实体与值对象、聚合与聚合根、领域服务与领域事件、分层与依赖。适合已经写过几年业务代码、被复杂业务规则折磨过、想系统梳理一遍DDD底层概念的人看如果你手上只是几个字段的增删改查坦率讲DDD 带来的是负担而不是收益。1. 先搞清楚DDD的适用边界它治的是业务复杂度不是技术复杂度我见过不少团队在技术选型会上把DDD搬出来理由五花八门比如“微服务要拆所以得上DDD”“代码太乱了用DDD重构一下”。这种出发点通常撑不过三个月。DDD 的原始定位非常明确它针对的是业务领域的复杂性而不是并发、性能、分布式事务这类技术复杂性。这两类复杂性需要的是完全不同的工具把DDD当成技术复杂度的手术刀结果往往是引入了一堆新概念业务规则反而更散。1.1 业务复杂度的三个典型信号判断一个系统到底需不需要DDD我一般看三个信号出现两个以上才值得投入。第一个信号是业务规则的数量和变化频率。比如计价规则不是简单的“单价乘数量”而是会员等级、促销叠加、税费计算、阶梯折扣、退款冲抵互相纠缠而且每隔一两个月就有新的营销活动要接进去。这种规则一旦用 if-else 堆起来半年之后就没人敢动了。第二个信号是同一业务概念在不同部门之间语义分裂。开头说的“订单”就是典型。当同一个词在不同上下文里含义不同而这几个上下文又要频繁协作时光靠开会同步是治不好的必须有明确的边界和翻译机制。第三个信号是多人长期协作带来的模型腐蚀。一个模块从三个人维护变成十五个人维护每个人按自己的理解往里面加字段、加状态两年后这个模型的原始设计意图已经完全看不出来了。这时候缺的不是重构而是模型本身的表达力。反过来看如果业务就是“表单提交、存库、列表展示”规则少、变化慢、单人维护那么用DDD反而会制造出大量空壳类一个只有 getter/setter 的实体、一个只做透传的领域服务、一个永远只有 findById 和 save 的仓储。这些类不减复杂度只增加导航成本。1.2 战略设计与战术设计不是一回事这是初学者最容易混淆的地方我自己也在这个坑里待过很久。DDD 分成两层战略设计管的是“系统怎么切分”。它包括通用语言、限界上下文、上下文映射、子域划分核心域、支撑域、通用域。这一层决定了团队边界和系统边界投入产出比最高但恰恰是最容易被跳过的一层。战术设计管的是“一个边界内部怎么建模”。它包括实体、值对象、聚合、聚合根、领域服务、领域事件、仓储、工厂。这一层是具体写代码时的工具箱。我踩过的坑是直接抱着《领域驱动设计》啃战术模式把实体、值对象、聚合全用上了代码看起来特别“DDD”但系统边界一塌糊涂三个上下文共用一套实体类最后领域层变成了一个巨型共享库。后来才明白战略设计错了战术设计做得再漂亮也只是给混乱加了一层精致的外壳。反过来战略设计做对了战术模式用得粗糙一点系统依然能长期演进。提醒如果你的团队连“某几个业务概念归谁负责”都还没谈清楚就先别急着画聚合、写领域事件那是把顺序搞反了。2. 通用语言先让所有人说同一种话再谈写同一种代码通用语言Ubiquitous Language是DDD里最朴素也最难落地的概念。它的定义很简单在一个限界上下文内业务人员、产品、开发、测试使用同一套词汇并且这套词汇直接体现在代码命名、数据库字段、接口文档、测试用例里。听起来是常识但实际操作起来阻力极大因为大部分团队的默认状态是“业务说业务的黑话开发说开发的黑话中间靠产品经理做人工翻译”。2.1 通用语言失效的三种典型形态第一种是文档型通用语言。团队认认真真搞了一次术语梳理产出一份三十页的词汇表放在知识库里然后就没有然后了。代码里依然是status、type、flag、kind混用词汇表变成了一份没人看的考古资料。通用语言不是文档是活的约定它必须出现在变量名、方法名、类名、接口路径、甚至聊天记录里。第二种是翻译层型通用语言。开发很努力地把业务词汇翻译成自己习惯的技术词汇比如业务说“授信额度”代码里叫creditLimit业务说“占用”代码里叫lock业务说“释放”代码里叫unlock。每个词单独看都合理但业务人员看代码完全看不懂开发看需求文档也要在心里做一次映射。映射本身不难难的是映射规则没人维护新人进来全靠口口相传半年后lock和freeze就混着用了。第三种是跨上下文强统一。有人觉得通用语言就该全公司统一于是把“客户”这个词强行统一成一个类。结果销售上下文里的客户是“有购买意向的联系人”结算上下文里的客户是“有信用账户的法人主体”客服上下文里的客户是“有历史工单的服务对象”。强行合并之后这个类膨胀到八十多个字段每个上下文只用到其中一小部分字段含义还得靠注释解释。这就是典型的把“通用语言”误解成了“全局语言”。2.2 让通用语言真正长进代码里的四个动作动作一从事件风暴开始收集词汇而不是从需求文档开始。需求文档往往是经过加工的事件风暴现场业务人员脱口而出的词才是真词汇。做法很简单把业务方拉到一块白板前让他们按时间顺序讲一遍业务流程每个动作写一张便签每个名词写一张便签。你会发现很多同义词“下单”和“创建订单”其实是同一件事和伪同义词“取消”和“关闭”其实差别很大。把这些分歧当场消掉比事后开会高效得多。动作二建立“词—代码”对照表并且纳入代码评审。我们当时做法是在项目根目录放一个GLOSSARY.md每个词条包含业务定义、所属限界上下文、代码中的类名/方法名/字段名、反例哪些写法是禁止的。代码评审时如果 PR 里出现了词汇表之外的业务概念命名评审人有权要求改名。这个规则执行了三个月之后命名一致性明显好转。动作三把通用语言写进测试用例的方法名。这一点特别有效但常被忽略。测试方法名用业务语言描述比如下单时会员折扣与优惠券不可叠加()比testCreateOrder3()有用一百倍。测试名是最贴近业务行为的代码文本用它来锚定通用语言成本极低。动作四允许上下文内部分裂但在边界上强制翻译。不同上下文对同一个词有不同定义是正常的甚至是必要的。关键是不能让两套定义直接碰撞。跨上下文调用时必须经过一层显式的翻译这个翻译在战术层面对应防腐层在战略层面对应上下文映射里的“客户方—供应方”关系。失效形态表面现象根本原因修正动作文档型词汇表躺在知识库里词汇未进入代码把词表纳入代码评审翻译层型业务看不懂代码开发看不懂需求缺少双向映射约定建立词—代码对照表跨上下文强统一单个类字段爆炸误把通用语言当全局语言按上下文拆分同名概念2.3 一个小的实践样本举个我们做过的例子。业务方反复说“额度占用”和“额度冻结”我们一开始以为是同义词合并成了freeze。后来在事件风暴里追问细节才发现占用是下单时临时扣减超时自动释放冻结是风控介入后的强制限制必须人工解冻。这两个行为的生命周期、触发方、释放条件完全不同。后来拆成了reserve占用和freeze冻结两个方法业务方看代码时一眼就能认出来测试用例也直接按这两个词组织。这件事让我确信通用语言的价值不在于统一而在于精确。3. 限界上下文与上下文映射给混沌的业务划出一条条可维护的缝限界上下文Bounded Context是DDD战略设计的核心它可以理解为“一个模型适用的边界”。在这个边界内某个业务概念有唯一确定的含义跨出边界同一个词可以有不同的含义而且不需要协调。这个定义听起来抽象落地时其实很好判断如果一个团队能独立决定某个概念的字段和规则不需要和别的团队同步那它就是一个限界上下文。3.1 划分限界上下文的四个现实依据教科书上常说要按“业务能力”划分这个说法太虚。我在实际项目里主要看四个现实依据依据一语言边界。如果两个团队对同一个词的争吵超过两次基本可以判定它们属于不同上下文。语言分裂是最可靠的信号因为它反映的是真实的业务认知差异而不是组织结构的一时变动。依据二变化频率。两个模块的发布节奏差异很大一个每周发版一个每季度发版强行放在一个上下文里会互相拖累。变动频率不同的部分边界往往也不同。依据三数据一致性要求。需要强一致的放在同一个聚合甚至同一个上下文里可以接受最终一致的就可以拆成不同上下文通过事件协作。这里要小心很多业务方嘴上说“必须强一致”追问下去其实“几秒内一致”就能接受。依据四团队规模与沟通成本。一个上下文最好由一个能坐在一起、能随时沟通的小团队负责。团队规模超过十几个人沟通成本会指数级上升这时候要么拆上下文要么拆团队反正得拆一样。需要注意的是限界上下文不等于微服务。一个上下文可以是一个模块、一个进程内的包也可以是多个服务反过来一个微服务里塞三个上下文也很常见。把两者划等号会逼着团队在业务边界还没想清楚的时候就去做分布式拆分那是灾难。3.2 上下文映射的几种关系与选型逻辑上下文划分出来之后它们之间必然要协作协作方式就是上下文映射Context Mapping。常见的关系有几种我按推荐程度从高到低排一下防腐层Anticorruption Layer是我最推荐的一种。做法是在自己的上下文里定义一套符合本地模型的接口外部上下文的数据进来时先经过一层转换器把外部模型翻译成本地模型。好处是外部模型变化时只需要改转换器本地领域模型不受污染。代价是多写一层映射代码。我的经验是只要对接的是外部系统、老旧系统或者第三方服务防腐层几乎是必选项省下的这层代码迟早会以更大的代价还回来。客户方—供应方Customer/Supplier适合上下游团队地位对等、能协商的场景。下游是客户上游是供应方双方约定接口契约上游变更前通知下游。这需要一定的组织成熟度否则容易变成上游单方面改接口、下游被动救火。开放主机服务Open Host Service 发布语言Published Language适合一个上下文要对接多个下游的场景。上游定义一套稳定的对外协议比如 REST 接口加 JSON Schema所有下游按这套协议对接。这本质上是在上下文边界上做了一层 API 网关式的抽象。遵奉者Conformist是下游完全跟随上游模型不做翻译。省事但代价是本地模型被外部模型绑架。只有在外部模型足够稳定、且本地业务确实没有独立表达需求时才考虑。共享内核Shared Kernel要极其谨慎。两个上下文共享一小部分模型代码看似省事实际上把两个团队的发布绑在了一起。一旦共享部分要改两边都得动。我的建议是共享内核越小越好最好只共享最基础的值对象比如金额、货币单位。各行其道Separate Ways常常被低估。如果两个上下文之间没有实质协作需求就干脆不要建立关系各做各的。很多所谓的“集成需求”其实是组织政治的产物不是业务需要。映射关系适用场景主要代价我的默认选择防腐层对接外部/遗留系统多一层转换代码外部依赖首选客户方—供应方内部上下游团队依赖组织协作成熟度内部上下游常用开放主机服务一对多对接上游需维护稳定契约平台型上下文常用遵奉者外部模型稳定且本地无独立表达本地模型被绑架慎用共享内核极少量基础类型共享发布耦合越小越好各行其道无实质协作无优先考虑4. 战术设计的四块积木实体、值对象、聚合、领域服务战略设计定完边界才轮到战术设计。这一层最容易出现的问题不是“不会用”而是“用过头”——把每个类都硬套成实体或值对象结果模型比业务本身还复杂。我的体会是战术模式是工具箱不是清单不需要每个都用上。4.1 实体与值对象判别标准只有一个实体Entity和值对象Value Object的区别教科书上说“实体有标识值对象没有”这个说法正确但不够用。我用的判别标准更实际这个东西换一个实例业务上是否等价举个例子。一笔转账记录里的“金额”100 元和另一笔 100 元在业务上是完全等价的谁拿着这 100 元不重要重要的是数值本身所以金额是值对象。而“账户”就不一样了账户 A 和账户 B 就算余额、类型、开户时间全都一样也是两个不同的账户因为有账号这个标识所以账户是实体。值对象的关键特征是不可变。一旦创建就不能修改要改就整体替换。这个约束很多人不适应觉得每次改个字段都要 new 一个新对象很麻烦。但正是这个约束带来了巨大的好处值对象可以安全地在多线程间传递、可以放心地做缓存、可以自由地做相等性比较不用担心被某个调用方偷偷改掉。// 值对象不可变整体替换相等性由属性决定 public final class Money { private final BigDecimal amount; private final String currency; public Money(BigDecimal amount, String currency) { if (amount null || currency null) { throw new IllegalArgumentException(金额与币种不可为空); } if (amount.scale() 2) { throw new IllegalArgumentException(金额精度不得超过两位小数); } this.amount amount; this.currency currency; } public Money add(Money other) { if (!this.currency.equals(other.currency)) { throw new IllegalArgumentException(币种不一致无法相加); } return new Money(this.amount.add(other.amount), this.currency); } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Money)) return false; Money money (Money) o; return amount.compareTo(money.amount) 0 currency.equals(money.currency); } Override public int hashCode() { return Objects.hash(amount.stripTrailingZeros(), currency); } }这段代码里有几个细节值得说。第一构造函数里做了校验非法状态根本创建不出来这比事后到处判断要可靠得多。第二add返回新对象而不是修改自身保证了不可变性。第三equals用compareTo而不是equals比较金额是为了处理100和100.00这种精度差异——这个坑我在实际项目里踩过两个金额明明相等用equals判断却是 false查了半天才发现是BigDecimal的 scale 不同。实体这边要注意的是标识的生成时机。很多项目习惯用数据库自增 ID 作为实体标识这在DDD里是有问题的实体在入库前就应该有标识否则领域层就没法判断两个对象是不是同一个。常见的做法是在领域层用 UUID 或者雪花算法生成标识数据库主键只是持久化细节。4.2 聚合与聚合根一致性边界不是对象树聚合Aggregate是DDD里最容易被误解的概念。很多人把它理解成“有包含关系的对象组合”于是设计出巨大的对象树一个订单聚合里塞进订单项、支付记录、物流信息、评价、优惠券……最后这个聚合加载一次要查七八张表保存一次要处理一堆并发冲突。聚合的本质是一致性边界和事务边界。它的定义是一组相关对象作为一个整体进行数据修改并且必须保证在事务结束后聚合内部的所有不变量都成立。这句话里有两个关键词关键词一不变量。聚合内部必须始终满足的业务规则。比如“订单总金额等于所有订单项金额之和”“订单项数量不能为负”。这些规则必须在聚合内部保证不能依赖外部定时任务去修。关键词二事务边界。一次事务只修改一个聚合。跨聚合的操作靠领域事件做最终一致而不是靠一个大事务包住。基于这两点聚合设计有几个硬性原则聚合根是外部访问的唯一入口外部不能直接持有聚合内部对象的引用聚合尽量小只把必须同时满足不变量的对象放进来聚合之间通过标识引用而不是对象引用一个事务只改一个聚合。拿订单举例。订单和订单项放一起是合理的因为“总金额等于各项之和”这个不变量必须同时保证。但支付记录就不该放进来支付有自己的生命周期和状态机它和订单之间是最终一致的关系应该独立成聚合通过领域事件通知订单更新状态。// 聚合根订单内部维护不变量外部只能通过聚合根访问 public class Order { private final OrderId id; private final ListOrderItem items new ArrayList(); private OrderStatus status; public Order(OrderId id) { this.id id; this.status OrderStatus.DRAFT; } public void addItem(ProductId productId, Money unitPrice, int quantity) { if (status ! OrderStatus.DRAFT) { throw new IllegalStateException(非草稿状态的订单不可追加条目); } if (quantity 0) { throw new IllegalArgumentException(条目数量必须为正); } items.add(new OrderItem(productId, unitPrice, quantity)); } public Money totalAmount() { return items.stream() .map(OrderItem::subtotal) .reduce(new Money(BigDecimal.ZERO, CNY), Money::add); } public void submit() { if (items.isEmpty()) { throw new IllegalStateException(空订单不可提交); } this.status OrderStatus.SUBMITTED; } public ListOrderItem items() { return Collections.unmodifiableList(items); } }注意items()返回的是不可变视图外部拿不到内部集合的修改权限所有变更必须走addItem这类聚合根方法。这是保证不变量的前提如果对外暴露了可变集合不变量随时可能被绕过。4.3 领域服务、领域事件与仓储什么时候该用什么领域服务Domain Service用于承载“不属于任何单一实体或值对象的业务行为”。典型场景是跨聚合的规则比如“转账时校验转出方余额是否充足并扣减同时增加转入方余额”这个行为同时涉及两个账户聚合。这里要注意领域服务不是“把实体搞不定的逻辑全丢进去”的垃圾桶判断标准是这个行为是否真的不属于某一个聚合根。如果属于就应该写成聚合根的方法。领域事件Domain Event表达“领域中发生的、其他部分可能关心的事实”命名用过去式比如OrderSubmitted、PaymentSettled。它的价值在于解耦下单之后要做的库存预占、积分计算、消息推送都不需要在订单聚合里显式调用发布事件即可。我踩过的坑是把领域事件直接当消息队列用在事件里塞了大量的跨系统调用逻辑结果领域层依赖了中间件客户端单元测试跑不起来。正确做法是领域事件只在领域层内部发布由应用层或基础设施层负责转发到外部消息系统。仓储Repository是聚合的持久化抽象注意几个边界一个聚合对应一个仓储仓储接口定义在领域层实现在基础设施层仓储只处理聚合根不处理聚合内部的非根对象仓储不是 DAO不应该有findByStatusAndCreateTimeBetween这种查询方法无限膨胀复杂查询应该走专门的查询服务或者 CQRS 的读模型。5. 分层与依赖DDD的代码结构到底长什么样概念都清楚了之后下一个问题就是“代码怎么组织”。这块最容易形式化——把包名改成domain、application、infrastructure就宣称自己用了DDD实际依赖关系还是乱的。5.1 四层架构的依赖方向是核心经典的四层是用户界面层或接入层、应用层、领域层、基础设施层。关键不在分成几层而在于依赖方向领域层必须是最纯粹的一层不依赖任何外部框架、数据库、消息队列基础设施层负责实现领域层定义的接口依赖倒置。层次职责允许依赖典型内容接入层协议适配、参数校验、鉴权应用层Controller、RPC 入口应用层用例编排、事务边界、权限领域层ApplicationService领域层业务规则、状态流转无仅语言基础库实体、值对象、聚合、领域服务基础设施层持久化、消息、外部调用领域层接口Repository 实现、事件发布器很多项目的领域层里出现了Entity、Table这类 ORM 注解或者直接 import 了某个 HTTP 客户端这就是依赖方向被破坏了。短期看不出问题长期后果是领域模型和数据库表结构死死绑在一起业务想换个存储方式或者写个纯内存的单元测试都做不到。应用服务Application Service和领域服务Domain Service的区别也常被搞混。应用服务负责“编排”——接收请求、加载聚合、调用领域方法、保存聚合、发布事件、处理事务它本身不应该包含业务规则。领域服务则包含业务规则但不处理事务和持久化。判断标准很简单如果一段代码里出现了Transactional它大概就是应用服务如果出现了业务判断它大概属于领域层。5.2 从贫血模型迁移到充血模型的可行路径绝大多数存量项目都是贫血模型实体只有字段和 getter/setter业务逻辑全在 Service 里。直接推翻重写风险太大我实践过的渐进路径是这样的第一步先把值对象抽出来。这一步风险最低、收益最明显。金额、手机号、身份证号、地址这些概念从裸字段抽成不可变的值对象校验逻辑收进构造函数。这一步不改变整体架构但能立刻消灭大量重复校验代码。第二步把最稳定的业务规则搬进实体。挑那些规则简单、调用点集中的方法比如订单状态流转、库存扣减校验从 Service 里搬进聚合根。搬运时保持 Service 方法签名不变内部改为委托给聚合根这样调用方无感知。第三步识别并收敛聚合边界。这一步最难需要梳理哪些对象必须在一个事务里修改。可以先用“如果一个操作需要同时改 A 和 B 且必须原子那它们可能属于同一个聚合”这个粗糙标准做初筛再逐个验证不变量。第四步把跨聚合协作改成领域事件。当聚合边界清晰之后原来在一个大事务里做的多表更新逐步拆成“改一个聚合 发布事件 订阅方异步处理”。这条路径走下来通常需要几个月而且中间状态会有点难看但比一次性重写稳得多。我在一个中等规模系统上走过一遍最大的感受是不要试图一次改完也不要为了“看起来像DDD”而改每一步都应该有明确的业务收益否则就是纯粹的形式主义。6. 学DDD这段时间踩过的几个典型坑概念学完到真正用对中间隔着一段很长的弯路。下面这几个坑我基本都踩过写出来供参考。坑一把DDD当成分层架构的改名运动。最容易发生的情况是包结构改成四层实体类加上几个业务方法然后宣布迁移完成。但限界上下文没划、通用语言没统一、聚合边界没想清楚结果只是把原来的大泥球换了个容器装着复杂度一点没少。判断有没有真的用起来我用的标准是能不能指着代码说出每个聚合的不变量是什么并且这些不变量确实由代码保证。说不出来大概率还是贫血模型换了张皮。坑二聚合设计过大。一开始总觉得“这些数据都相关放一起方便”于是聚合越画越大。后果是并发冲突频发——两个人同时操作同一个聚合的不同部分因为聚合是一个事务边界只能串行。正确的做法是问自己这两部分数据是否必须同时满足某个不变量如果不是就拆开。坑三通用语言只存在于会议纪要里。会上大家统一了叫法散会后各写各的。这个坑的解法前面说过就是让词汇进入代码评审、进入测试方法名靠流程而不是靠自觉。坑四过度使用领域事件。领域事件很好用但用多了会让调用链路变得难以追踪。我现在的原则是同步能解决、且没有性能问题的就不用事件。事件适合表达“已经发生的事实”和“跨聚合的最终一致”不适合用来做流程编排。坑五把防腐层写成纯粹的字段搬运。防腐层的价值在于把外部模型翻译成本地模型如果只是把外部 DTO 的字段一个个赋值到本地对象那这层就白写了。真正的防腐层应该做语义转换外部系统的“状态 3”要翻译成本地的“已确认”外部的金额单位是分要转换成本地的元外部的枚举值要映射成本地的枚举。这些转换规则集中在一处外部系统变更时才不用满项目找。坑症状判断方法修正方向改名运动包名对了模型还是贫血的说不出聚合不变量从值对象和不变量入手聚合过大并发冲突多、加载慢一次事务改多张表按不变量拆分聚合语言失效代码命名与业务词汇脱节业务方看不懂代码词表进评审事件滥用链路难追踪、调试困难简单流程也走事件同步优先防腐层空转只有字段赋值没有语义转换外部变更仍需大改补语义映射规则最后分享一个我觉得挺有用的小技巧给每个限界上下文写一份不超过一页的“边界说明”内容包括这个上下文负责什么、不负责什么、对外暴露哪些能力、依赖哪些外部上下文、这个上下文里的核心词汇表。这份说明放在代码仓库里新人进来第一件事就是读它。写了半年之后我发现这份文档最大的价值不是给新人看的而是逼着团队自己把边界想清楚——很多模糊地带在写说明的过程中就暴露出来了。再补一句关于学习路径的体会。DDD 的书不容易读概念之间的依赖关系是网状的单独看“聚合”很难理解为什么要这么设计得先理解限界上下文和一致性边界。我自己的顺序是先搞明白通用语言和限界上下文这两件事哪怕不写代码也能实践再回头啃实体、值对象、聚合最后才是领域事件和架构分层。反过来从战术模式入手很容易学成一堆孤立的代码技巧。
