1. 先破题为什么“DDD 搞不懂”是多数人的真实状态我见过太多团队在 DDD 这件事上从“跃跃欲试”到“越搞越懵”最后草草收场。翻翻技术社区里关于 DDD 的讨论你会发现一个有意思的现象代码写得深的人觉得 DDD 就是一堆名词概念画图画得勤的人觉得 DDD 就是领域模型加仓库做架构规划的人觉得 DDD 就是拆微服务和建中台。大家各说各话谁也说服不了谁。而热搜词里长期存在“ddd架构”和“ddd搞不懂”这对矛盾组合本身就已经说明问题了——DDD 既有让人趋之若鹜的魅力又有让人摸不着头脑的门槛。之所以普遍搞不懂我先说三个关键原因。第一个原因是 D 领域模型不是技术模型。很多人习惯用表结构、接口、类继承去理解业务但 DDD 恰恰要求你先忘记技术实现贴着业务语言走。这一下子就击穿了不少人的舒适区。第二个原因是战术设计和战略设计被混为一谈。网上大量资料讲的是聚合、实体、值对象这类战术工具可一到实际问题你面临的多半是系统如何拆分、团队如何协作、中台能力如何共享这类战略问题。拿战术工具去解战略题目自然到处碰壁。第三个原因是缺少一条从单服务到分布式架构的连贯路径。大部分人学 DDD 时没有一条清晰的演进路线今天看一篇“聚合的最佳实践”明天看一篇“事件风暴操作指南”知识点零零散散形不成闭环。这篇文章想做的事情很简单给“DDD 搞不懂”的人画一张完整的地图。 我会从单服务的战术落地开始把实体、聚合、六边形架构这些基础构件讲透然后过渡到分布式系统下的边界重构说清楚为什么单服务里那套模型不能直接放大最后进入分布式中台的战略设计把事件风暴、上下文映射、防腐层这些战略工具串起来。整体读下来你会知道 DDD 从不只是写代码的风格它是一套从业务洞察到系统架构的完整认知框架。2. 单服务战术落地DDD 的最小可用闭环2.1 战术建模的四大构件从概念到直觉战术设计是整个 DDD 操作体系的切入点所谓战术就是指在限界上下文内部把领域模型建出来并映射到代码结构中。核心构件有四个实体、值对象、聚合和领域服务它们不是并列的四个名词而是有层次关系的。实体很好理解就是有唯一标识、且会经历状态变化的对象。订单、用户、账户都是典型实体它们的身份在整个生命周期内不变变的只是属性。值对象是另一个极端它没有独立身份把一组属性打包后整体有意义。比如一个收货地址它由省市区、街道、门牌号构成你不需要跟踪一个地址“从 A 变成 B”的轨迹只要整体替换即可。绝大多数初学者的第一个建模误区就是把什么都建模成实体结果系统里充斥着大量“身份感极弱”的对象模型复杂度无端升高。聚合则是实体和值对象的上层容器。 它解决的是“一致性边界”的问题。一次业务操作中哪些数据必须在一个事务内被同时更新这个边界就是聚合边界。聚合内有一个聚合根外部对象只能通过聚合根访问聚合内部的数据不能绕过聚合根直接修改内部实体。设计聚合时我在实践中有一条朴素的标准——从业务一致性出发而不是从数据表关系出发。比如订单和订单明细它们必须同生共死明细不能脱离订单独立存在所以它们天然属于同一个聚合聚合根是订单。而订单和客户则是两个不同的聚合客户挂了订单还是历史事实订单不会因为客户信息变化而重建身份它们之间是聚合与聚合的关系只能通过订单聚合根访问。领域服务的存在是为了承载那些不属于任何实体或值对象的业务逻辑。典型例子是转账钱从 A 账户到 B 账户涉及两个账户聚合的状态变化没有哪个账户天然是“转账”这个行为的归属者那就用领域服务来编排。判断一个逻辑到底应该放在实体内部还是提成领域服务我有一个经过多次打磨的经验——看领域语言是否足够自然。人话就是这句话说成“订单自己计算总额”更顺还是“订单计算服务负责计算总额”更顺。如果动词天然属于某个对象就放对象里如果动词属于跨对象的交互行为才提领域服务。这个原则说起来简单实战中却能避免大量“逻辑无处安放”的争论。2.2 战术落地实操从订单模型到代码骨架理论不多讲直接上一个最小可用的订单域案例。假设我们要做电商系统的订单模块业务规则如下用户提交订单时订单至少包含一个明细项明细项需校验商品的库存和价格订单总额由所有明细金额求和得到提交后的订单不可直接修改只能取消或确认付款。基于这些规则聚合设计应该是这样的订单作为聚合根内部持有订单明细列表明细就是值对象或内部实体取决于你是否需要追踪明细的独立变化。库存是另一个聚合商品又是另一个聚合。订单模型代码如下以 Java 为示例语言public class Order { private OrderId id; // 值对象 private CustomerId customerId; // 引用外部聚合的标识 private ListOrderItem items; // 明细列表 private OrderStatus status; // 枚举或值对象 public void submit() { if (items.isEmpty()) { throw new BusinessException(订单至少包含一个商品); } this.status OrderStatus.SUBMITTED; } public Money calculateTotal() { return items.stream() .map(OrderItem::getSubtotal) .reduce(Money.ZERO, Money::add); } public void cancel() { if (this.status ! OrderStatus.SUBMITTED) { throw new BusinessException(只有已提交的订单可以取消); } this.status OrderStatus.CANCELLED; } }注意一个细节Order 类里没有 setStatus 这种直接修改方法入口所有状态变更都封装在业务方法内部。用户取消订单时你不能 new Order 然后 setStatus(CANCELLED)必须调用 cancel() 方法。这就是战术落地阶段最核心的纪律——让业务规则约束代码入口。 很多团队做 DDD 做到一半变成“贫血模型 一堆 Service”就是因为允许外部拿到实体后直接改状态领域规则散落到各个 Service 里模型变成壳子。六边形架构和 DDD 的搭配在这一步就显示出优势了。六边形架构把系统分为领域核心、输入端口、输出端口三层。领域核心就是上面写的 Order、Money、独立于外部框架输入端口侧有 API 接口、消息监听器输出端口侧有仓库、外部服务调用。端口和适配器分离后订单服务的业务逻辑完全不依赖 Spring 或 MyBatis 这些技术框架控制器和仓库都成了插拔式适配器。你换数据库订单核心代码一行都不用改你加一个消息队列消费者入口也只是多实现一个输入端口而已。我听很多人说“六边形架构和 ddd 天然合拍”其实合拍的本质在于DDD 让业务模型变得高内聚六边形架构让技术依赖变得低耦合两者关注的点互补拼接起来正好是完整的分层方案。2.3 单服务战术落地最容易踩的三个坑战术落地的成败往往不在于你掌握了多少 DDD 概念而在于是否避开了那些反模式。第一个坑是“表驱动建模”。 我见过不少团队做 DDD第一步不是分析业务而是打开数据库看表结构然后把每张表对应成一个实体最后加一层 Service 包一下美其名曰“我们用了 DDD”。这种做法的本质是拿 ORM 的思维套领域模型表外键关系代替了聚合边界业务不变式根本没有落到代码里。要破这个局建模前先把表结构扔到一边从用例和事件出发画出业务如何流转再反推模型应该长什么样。第二个坑是“聚合设计过小或过大”。聚合过小比如把订单和明细拆成两个聚合会导致明细的添加和修改很难保证事务一致性最终只能用分布式事务去补窟窿复杂度不降反升。聚合过大比如把订单、客户、库存、物流全部装进一个大聚合里结果任何一个无关小操作的提交都要锁全聚合并发直接被打爆。聚合边界的度量标准就是“一次业务操作需要原子更新的最大范围”范围之外的尽量不做硬性绑定。第三个坑是过度设计。刚上手 DDD 的人动不动就想给所有对象分实体还是值对象给所有行为找领域服务结果模型比业务还复杂。我的体会是建模初期允许模糊有些对象先当实体用随着业务演进再重构为值对象领域服务也多以“编排少量聚合交互”为限不要用领域服务去编排整个世界。DDD 不是用来证明你概念记得多的它的目标始终是让复杂领域变得可理解、可维护。3. 从单服务到分布式边界的本质变化3.1 同一个聚合模型为什么放大到微服务就失败很多团队的崩溃点出现在把单服务里已经跑通的 DDD 模型直接搬进微服务架构时。单体里一个订单聚合里面查库存、扣优惠券、算价格全在一个进程内完成事务和一致性都靠数据库保证。拆分后订单服务、库存服务、优惠券服务各自独立部署原来聚合内部的一致性边界被物理机器劈开了。你不可能再指望一个数据库事务去扣库存的同时改订单状态这时候分布式事务要么性能差到无法接受要么根本不可行。这个问题的根源是当架构从单服务转向分布式时你原本基于“进程内调用 数据库事务”的假设被打破了。 聚合边界不再只是业务一致性边界同时被技术一致性边界约束。解决矛盾的方向不是到处引入分布式事务而是重新审视聚合边界是否划得合理。这时候我就会反复问团队一个问题某个数据的一致性要求到底强到什么程度如果库存扣减和订单确认可以容忍短暂的中间状态那就应该把这两个聚合拆到不同服务用事件驱动加最终一致性去衔接如果某个一致性是业务红线比如账户扣款和流水记账必须同时成功那这两个聚合就应该坚定地放在同一个服务甚至同一个聚合里不要让分布式边界从内部穿过。这里必须强调一个容易被忽略的原则单体里的聚合边界划分标准到了分布式架构下要重新过一遍。 单体中因为事务成本低而随意合并的聚合在拆分后可能变成性能瓶颈单体中因为调用方便而松散关联的聚合在拆分后又可能变成分布式通信的负担。我见过一个支付系统拆服务时把“订单主单”和“订单支付记录”放进了同一个服务理由是它们都是订单域的。结果支付记录增长极快归档需求频繁主单服务每次发布都被数据量拖累最后不得不拆库拆表反而比当初正确划分边界多花了两倍工作量。3.2 聚合、限界上下文、微服务边界三者之间的真实关系初学者最容易混淆的一组概念就是聚合边界、限界上下文和微服务边界。我用一句话来区分聚合边界是数据一致性边界限界上下文是业务语言边界微服务边界是部署运维边界。三者有关联但绝对不等同。限界上下文是 DDD 战略设计里最重要的词它指一个明确边界内的业务模型和统一语言。同一个“客户”概念在销售上下文里关心的是联系方式、购买偏好和订单记录在风控上下文里关心的是黑名单状态、可疑行为记录、信用评分它们完全是两个不同模型。 试图让所有上下文共享同一个客户实体是典型的大型系统腐败点。正确的做法是让每个限界上下文自主建模上下文之间通过明确的接口通信。微服务边界应该天然追随限界上下文边界。一个限界上下文里的多个聚合如果业务关系紧密、数据访问模式相近、团队协作频繁完全可以放进一个微服务如果某个聚合演进速度极快、独立扩展需求突出也可以单独拆成服务。 我推荐的原则是“最小可行的服务最大必要的聚合”——一个服务至少包含一个聚合服务边界不打破聚合一致性多个聚合放进一个服务的前提是它们不会因为独立部署而频繁产生跨服务事务。举一个真实演进案例某零售系统最初的“商品上下文”里有商品基础信息聚合、商品价格聚合、商品库存聚合。上线后发现商品基础信息改动频率低但访问量巨大库存改动频率极高并发压力大价格聚合与促销上下文耦合紧密。后来团队把库存聚合拆成独立服务把价格聚合迁入促销上下文商品上下文只剩下基础信息聚合。三次改动都没有碰聚合内部的模型只是调整服务边界这正是“聚合稳定、服务灵活”的好处。3.3 事件驱动分布式系统下替代分布式事务的核心支撑分布式系统里如果目标不是“强一致”而是“最终一致”那事件驱动就是最常用的战术工具。核心思路是聚合在自己的事务边界内完成状态变更然后发布领域事件其他限界上下文订阅事件执行自己的本地更新。整个过程不出现跨库事务每个参与方都通过事件消息产生异步耦合。还是以订单和库存为例订单服务在确认订单的本地事务里落库订单状态同时发布 “OrderConfirmed” 事件。库存服务订阅到这个事件后在自己的数据库事务里扣减库存。这里有两个细节必须严格把控。第一事件发布和本地事务必须原子化。 否则会出现订单状态已提交但事件没发出去库存不扣超卖风险随之而来。常见方案是“本地消息表 消息队列”或者“事务性发件箱”先把事件落地到同库的表里再由后台任务或监听器转发到消息中间件。第二消费者必须按业务规则处理幂等。 消息队列虽然很多已经做到“至少一次”投递但消费端代码切换或网络异常仍可能收到重复事件库存扣减必须支持幂等重放。事件的选择也要谨慎。不是所有业务改动都值得发事件事件的价值在于通知“对别人有意义的事情”。订单确认事件有意义因为库存、支付、物流都关心订单状态字段从“A”改到“B”这种内部实现变化就不值得发事件。 事件命名要采用过去时用统一语言描述已经发生的事实比如 OrderConfirmed、PaymentReceived而不是 OrderStatusChanged 这种纯数据变化的说法。4. 分布式中台战略全景从战术工具到战略设计4.1 中台的本质为什么是共享能力域再造这几年“中台”这个词被滥用得厉害很多公司把中台理解成一个独立的项目组或者一堆被拆出来的公共服务。但从 DDD 的战略视角看中台的本质是跨多个业务线的共享能力域它是一个限界上下文的集合而不是一个技术平台。我判断中台建设是否成功的标准很简单业务方是否可以在不反复解释业务术语的情况下直接复用中台提供的领域能力。 如果业务方要调用中台的商品服务却还要向中台团队解释什么是“促销价”、什么是“阶梯价”那说明中台并没有形成自己的统一语言它只是一个技术包装过的共享数据库。那么中台能力从哪来它来自对多个业务线的共性提炼。比如订单中台要支撑电商、门店收银、B2B 批发、第三方代销就必须抽象出订货、履约、结算这些领域的共性模型同时让各业务线以扩展点方式承载差异性。 DDD 在这个过程中能提供的是清晰的上下文映射和各上下文间的接口治理而不是一个“自下而上把所有共性需求收集起来”的需求池。中台最怕的是做成需求收集器业务线提一个需求中台加一个功能最后中台变成一个大泥球谁都在用谁也改不动。在设计共享能力时有一条战略层面的通用规律共享的是能力不是数据所有权。 中台向业务线输出“商品查询能力”“库存扣减能力”但商品数据的归属仍然在中台上下文里业务线通过 API 或领域事件获得所需视图而不是直连中台数据库更不应该把自己的数据库和中台数据库做成同步复制。这样做会让中台退化成一个“中央数据仓库”领域逻辑反而无处安放。4.2 战略设计工具箱事件风暴与上下文映射分布式中台战略设计的起点不是画架构图而是先把业务事件梳理清楚。事件风暴就是这样一种轻量高互动的工作坊方法业务专家、架构师、开发人员围坐一起用彩色贴纸把领域事件、命令、聚合角色逐步贴到长墙上。整个过程非常直接——事件是橘色贴纸命令是蓝色贴纸聚合是黄色贴纸领域专家看到的是自己熟悉的“发生了什么”的语句技术人员看到的是模型和边界双方用同一种语言对话。我做过的有效事件风暴开场从来不问“你们系统有哪些模块”而是顺着一个端到端的业务旅程走用户下单时发生了什么系统支付时发生了什么物流发货时发生了什么 一条业务主线走完后再对每个事件追问谁触发了这个事件这个事件会导致什么后续事件哪些规则必须在这个事件发生前满足这种追问会自然暴露出聚合的雏形以及不同聚合之间的协作关系比闭门建模高效得多。事件风暴之后紧接着要做上下文映射。上下文映射的工具包括几种关系类型{% message_patterns %}合作关系、共享内核、客户-供应商、防腐层、开放主机服务。那些相互独立、通过事件或 API 集成的上下文通常用客户-供应商或开放主机服务的关系需要共享某些模型结构的则可能引入共享内核或合作关系。防腐层的角色尤为重要它的存在是为了保护一个新开发的上下文不受外部老旧系统或语义混乱系统的模型污染。 我在一个项目中负责的商品上下文要对接一个含义混乱的第三方库存系统就在边界处写了一个防腐层把第三方接口的磁盘参数、状态码全部翻译成本上下文专用的库存模型。防腐层内的翻译代码虽然琐碎但它确保了三方系统的混乱不会渗透到我们精心设计的领域模型里。4.3 战略设计绕不开的组织问题康威定律的映射DDD 战略设计如果只停留在图纸上落地时必然碰壁因为系统的最终形态一定是组织结构的缩影。康威定律说得很直白设计系统的组织其沟通结构往往会镜像到系统架构中。 中台要和多个业务线协作如果组织上中台团队以项目组机制独立运作业务线需求以瀑布方式排队那么中台与业务线之间一定会形成巨大的上下文鸿沟。所以战略设计里有一个 DDD 衍生出的重要实践——“限界上下文优先的组织架构”。 每一个限界上下文都应该有清晰的代码库归属和团队归属。反例是很多公司按照技术职能划分团队数据库组管所有数据模型后端组管所有业务核心前端组管所有接口交互。这会导致一个限界上下文内的领域逻辑被三个团队扯碎统一语言完全失效。正例是让一个全职能团队负责一个上下文前后端、测试、数据库都是团队内成员这个团队对业务模型和模型演进有完全控制权。我见过的最成功的中台实践是让中台以“能力域团队”方式运作每个能力域对应一个限界上下文能力域团队独立排期、独立发布、独立度量业务指标。中台不设一个庞大的统一组织而是由一个个专注共享能力的自治团队组成他们之间通过契约和事件协作而不是通过集团管理强行合并。这样做系统的边界才能真正稳定下来中台战略才可能从 PPT 变成经得起业务迭代考验的基础设施。4.4 战略设计中最容易翻车的地带分布式中台战略失败案例的共同点我总结下来有三个。第一把事件风暴变成一次性的年终团建。 事件风暴不是一次活动而是一个持续演进的建模循环。业务变化后事件风暴应该重新召集领域专家重新审视事件流和上下文边界。很多团队做完一次事件风暴就像交差一样后面模型腐化了也毫无知觉。正确的做法是把事件风暴做成每个迭代可重复进行的轻量流程至少每季度回顾一次上下文映射关系。第二上下文映射只画不执行。 很多人画完上下文映射图觉得自己已经完成了战略设计然后各团队照旧各写各的接口契约没有任何治理。上下文映射图的真正产出物不是图本身而是图中每个关系的明确协作协议谁是上游、谁是下游、接口版本如何演进、防腐层代码谁维护、事件发布和订阅的契约如何变更。这些协议如果没有落实到代码仓库、接口文档和团队工作协议里图就只是一张精美的废纸。第三试图一步到位建设大而全的中台。 中台建设最忌讳一开始就把所有业务线共性和差异一次性摸清然后规划一个宏观全景最后花一年时间实施。这个路径几乎必死因为业务机会和业务结构在一年内早就变了。可行的路径是先选一条价值最高的业务线做试点在试点中提炼出共享上下文形成基线模型再逐步扩展。 中台是从具体业务场景中长出来的不是从上而下的蓝图堆出来的。5. DDD 落地的路线图与速查表5.1 从 0 到 1 的推荐落地路线如果你所在团队正准备引入 DDD我会建议按下面五步走每一步都有明确的退出条件避免陷入无限讨论。第一步选一个被当前代码折磨得最厉害的业务模块而不是选一个最核心的模块。 被折磨的模块痛点明显团队有改变动力成功后的对比也更直观。第二步开展事件风暴工作坊产出事件流和初步聚合列表这一步最多安排两到三个半天。 第三步在单服务范围内完成战术落地把聚合模型映射到代码用六边形架构组织依赖方向跑通一个完整的用户故事。 第四步在同一业务域内尝试拆分服务边界引入事件驱动替换本 need 要在跨服务处使用的事务调用验证最终一致性链路。 第五步如果你所在组织有多个业务线共享能力的诉求再启动中台项目用事件风暴和上下文映射设计共享能力域按试点业务线逐步推广。每一步和下一步之间都有依赖关系我不建议跳步。 没做过战术落地就直接做中台战略设计很容易落入“纸面架构”的陷阱只做单服务战术而完全不考虑分布式边界则容易在系统拆分时重新陷入混乱。DDD 的价值不在于让你突然拥有某项神奇技能而在于让你从单点代码优化一路贯通到整个企业级系统的架构决策。5.2 常见问题排查速查表现象原因排查方向领域模型变成贫血模型业务规则被搬到 Service 层检查是否能不通过 Service 直接调用实体业务方法完成核心操作聚合频繁跨服务通信服务边界拆分过细重新审视哪些聚合属于同一限界上下文考虑合并服务分布式事务满天飞事件驱动替代不彻底梳理哪些一致性可以放宽为最终一致引入事件发布与订阅模型和表结构高度耦合表驱动建模暂时抛开表结构从用例和事件流重新建模业务方和开发方对概念理解不一致缺乏统一语言建立词汇表开发人员参与事件风暴使用业务术语命名代码事件风暴做完没有落地产物上下文映射与接口契约缺失明确每个上下文关系的协议、接口版本管理和防腐层归属中台服务被业务线绕过直接操作数据数据所有权失控明确共享能力的边界禁止直连中台数据库提供 API 作为唯一入口团队按技术职能划分DDD 推行阻力极大限界上下文没有对应团队边界推动组织向能力域团队演进至少先从代码库归属和接口团队归属入手这张表是我在各种项目里反复验证过的排查清单遇到问题先按行对号入座比重新翻阅 DDD 原书来得快。5.3 最后补一句给正在推进 DDD 的人我个人在实际操作中的体会是DDD 最反直觉的地方在于它看起来是一堆方法论但真正推进时卡点全部出现在沟通和协作上。 事件风暴的价值不是那张满是贴纸的照片而是领域专家、开发、测试在同一个房间里对业务达成共识的那几个小时。上下文映射的价值也不是那一张线框图而是让两个团队坐下来谈契约、谈协作协议、谈模型边界的那几个下午。如果你的组织连坐下来把业务聊清楚的意愿都没有DDD 的任何工具都帮不上忙。另外分享一个非常实用的小技巧在做战术落地时不要追求所有聚合都“纯净无依赖”过度设计反而会让代码难以落地。先用最朴素的代码把业务规则封装好让测试锁定核心行为然后随着你对领域的理解加深再逐步重构出更适合当前业务形态的聚合边界。 DDD 是迭代出来的不是设计出来的。这也是我从大量实战项目中得到的最终结论——认知升级永远是一个过程而不是一次顿悟。
从单服务到分布式中台：DDD落地的完整认知地图
1. 先破题为什么“DDD 搞不懂”是多数人的真实状态我见过太多团队在 DDD 这件事上从“跃跃欲试”到“越搞越懵”最后草草收场。翻翻技术社区里关于 DDD 的讨论你会发现一个有意思的现象代码写得深的人觉得 DDD 就是一堆名词概念画图画得勤的人觉得 DDD 就是领域模型加仓库做架构规划的人觉得 DDD 就是拆微服务和建中台。大家各说各话谁也说服不了谁。而热搜词里长期存在“ddd架构”和“ddd搞不懂”这对矛盾组合本身就已经说明问题了——DDD 既有让人趋之若鹜的魅力又有让人摸不着头脑的门槛。之所以普遍搞不懂我先说三个关键原因。第一个原因是 D 领域模型不是技术模型。很多人习惯用表结构、接口、类继承去理解业务但 DDD 恰恰要求你先忘记技术实现贴着业务语言走。这一下子就击穿了不少人的舒适区。第二个原因是战术设计和战略设计被混为一谈。网上大量资料讲的是聚合、实体、值对象这类战术工具可一到实际问题你面临的多半是系统如何拆分、团队如何协作、中台能力如何共享这类战略问题。拿战术工具去解战略题目自然到处碰壁。第三个原因是缺少一条从单服务到分布式架构的连贯路径。大部分人学 DDD 时没有一条清晰的演进路线今天看一篇“聚合的最佳实践”明天看一篇“事件风暴操作指南”知识点零零散散形不成闭环。这篇文章想做的事情很简单给“DDD 搞不懂”的人画一张完整的地图。 我会从单服务的战术落地开始把实体、聚合、六边形架构这些基础构件讲透然后过渡到分布式系统下的边界重构说清楚为什么单服务里那套模型不能直接放大最后进入分布式中台的战略设计把事件风暴、上下文映射、防腐层这些战略工具串起来。整体读下来你会知道 DDD 从不只是写代码的风格它是一套从业务洞察到系统架构的完整认知框架。2. 单服务战术落地DDD 的最小可用闭环2.1 战术建模的四大构件从概念到直觉战术设计是整个 DDD 操作体系的切入点所谓战术就是指在限界上下文内部把领域模型建出来并映射到代码结构中。核心构件有四个实体、值对象、聚合和领域服务它们不是并列的四个名词而是有层次关系的。实体很好理解就是有唯一标识、且会经历状态变化的对象。订单、用户、账户都是典型实体它们的身份在整个生命周期内不变变的只是属性。值对象是另一个极端它没有独立身份把一组属性打包后整体有意义。比如一个收货地址它由省市区、街道、门牌号构成你不需要跟踪一个地址“从 A 变成 B”的轨迹只要整体替换即可。绝大多数初学者的第一个建模误区就是把什么都建模成实体结果系统里充斥着大量“身份感极弱”的对象模型复杂度无端升高。聚合则是实体和值对象的上层容器。 它解决的是“一致性边界”的问题。一次业务操作中哪些数据必须在一个事务内被同时更新这个边界就是聚合边界。聚合内有一个聚合根外部对象只能通过聚合根访问聚合内部的数据不能绕过聚合根直接修改内部实体。设计聚合时我在实践中有一条朴素的标准——从业务一致性出发而不是从数据表关系出发。比如订单和订单明细它们必须同生共死明细不能脱离订单独立存在所以它们天然属于同一个聚合聚合根是订单。而订单和客户则是两个不同的聚合客户挂了订单还是历史事实订单不会因为客户信息变化而重建身份它们之间是聚合与聚合的关系只能通过订单聚合根访问。领域服务的存在是为了承载那些不属于任何实体或值对象的业务逻辑。典型例子是转账钱从 A 账户到 B 账户涉及两个账户聚合的状态变化没有哪个账户天然是“转账”这个行为的归属者那就用领域服务来编排。判断一个逻辑到底应该放在实体内部还是提成领域服务我有一个经过多次打磨的经验——看领域语言是否足够自然。人话就是这句话说成“订单自己计算总额”更顺还是“订单计算服务负责计算总额”更顺。如果动词天然属于某个对象就放对象里如果动词属于跨对象的交互行为才提领域服务。这个原则说起来简单实战中却能避免大量“逻辑无处安放”的争论。2.2 战术落地实操从订单模型到代码骨架理论不多讲直接上一个最小可用的订单域案例。假设我们要做电商系统的订单模块业务规则如下用户提交订单时订单至少包含一个明细项明细项需校验商品的库存和价格订单总额由所有明细金额求和得到提交后的订单不可直接修改只能取消或确认付款。基于这些规则聚合设计应该是这样的订单作为聚合根内部持有订单明细列表明细就是值对象或内部实体取决于你是否需要追踪明细的独立变化。库存是另一个聚合商品又是另一个聚合。订单模型代码如下以 Java 为示例语言public class Order { private OrderId id; // 值对象 private CustomerId customerId; // 引用外部聚合的标识 private ListOrderItem items; // 明细列表 private OrderStatus status; // 枚举或值对象 public void submit() { if (items.isEmpty()) { throw new BusinessException(订单至少包含一个商品); } this.status OrderStatus.SUBMITTED; } public Money calculateTotal() { return items.stream() .map(OrderItem::getSubtotal) .reduce(Money.ZERO, Money::add); } public void cancel() { if (this.status ! OrderStatus.SUBMITTED) { throw new BusinessException(只有已提交的订单可以取消); } this.status OrderStatus.CANCELLED; } }注意一个细节Order 类里没有 setStatus 这种直接修改方法入口所有状态变更都封装在业务方法内部。用户取消订单时你不能 new Order 然后 setStatus(CANCELLED)必须调用 cancel() 方法。这就是战术落地阶段最核心的纪律——让业务规则约束代码入口。 很多团队做 DDD 做到一半变成“贫血模型 一堆 Service”就是因为允许外部拿到实体后直接改状态领域规则散落到各个 Service 里模型变成壳子。六边形架构和 DDD 的搭配在这一步就显示出优势了。六边形架构把系统分为领域核心、输入端口、输出端口三层。领域核心就是上面写的 Order、Money、独立于外部框架输入端口侧有 API 接口、消息监听器输出端口侧有仓库、外部服务调用。端口和适配器分离后订单服务的业务逻辑完全不依赖 Spring 或 MyBatis 这些技术框架控制器和仓库都成了插拔式适配器。你换数据库订单核心代码一行都不用改你加一个消息队列消费者入口也只是多实现一个输入端口而已。我听很多人说“六边形架构和 ddd 天然合拍”其实合拍的本质在于DDD 让业务模型变得高内聚六边形架构让技术依赖变得低耦合两者关注的点互补拼接起来正好是完整的分层方案。2.3 单服务战术落地最容易踩的三个坑战术落地的成败往往不在于你掌握了多少 DDD 概念而在于是否避开了那些反模式。第一个坑是“表驱动建模”。 我见过不少团队做 DDD第一步不是分析业务而是打开数据库看表结构然后把每张表对应成一个实体最后加一层 Service 包一下美其名曰“我们用了 DDD”。这种做法的本质是拿 ORM 的思维套领域模型表外键关系代替了聚合边界业务不变式根本没有落到代码里。要破这个局建模前先把表结构扔到一边从用例和事件出发画出业务如何流转再反推模型应该长什么样。第二个坑是“聚合设计过小或过大”。聚合过小比如把订单和明细拆成两个聚合会导致明细的添加和修改很难保证事务一致性最终只能用分布式事务去补窟窿复杂度不降反升。聚合过大比如把订单、客户、库存、物流全部装进一个大聚合里结果任何一个无关小操作的提交都要锁全聚合并发直接被打爆。聚合边界的度量标准就是“一次业务操作需要原子更新的最大范围”范围之外的尽量不做硬性绑定。第三个坑是过度设计。刚上手 DDD 的人动不动就想给所有对象分实体还是值对象给所有行为找领域服务结果模型比业务还复杂。我的体会是建模初期允许模糊有些对象先当实体用随着业务演进再重构为值对象领域服务也多以“编排少量聚合交互”为限不要用领域服务去编排整个世界。DDD 不是用来证明你概念记得多的它的目标始终是让复杂领域变得可理解、可维护。3. 从单服务到分布式边界的本质变化3.1 同一个聚合模型为什么放大到微服务就失败很多团队的崩溃点出现在把单服务里已经跑通的 DDD 模型直接搬进微服务架构时。单体里一个订单聚合里面查库存、扣优惠券、算价格全在一个进程内完成事务和一致性都靠数据库保证。拆分后订单服务、库存服务、优惠券服务各自独立部署原来聚合内部的一致性边界被物理机器劈开了。你不可能再指望一个数据库事务去扣库存的同时改订单状态这时候分布式事务要么性能差到无法接受要么根本不可行。这个问题的根源是当架构从单服务转向分布式时你原本基于“进程内调用 数据库事务”的假设被打破了。 聚合边界不再只是业务一致性边界同时被技术一致性边界约束。解决矛盾的方向不是到处引入分布式事务而是重新审视聚合边界是否划得合理。这时候我就会反复问团队一个问题某个数据的一致性要求到底强到什么程度如果库存扣减和订单确认可以容忍短暂的中间状态那就应该把这两个聚合拆到不同服务用事件驱动加最终一致性去衔接如果某个一致性是业务红线比如账户扣款和流水记账必须同时成功那这两个聚合就应该坚定地放在同一个服务甚至同一个聚合里不要让分布式边界从内部穿过。这里必须强调一个容易被忽略的原则单体里的聚合边界划分标准到了分布式架构下要重新过一遍。 单体中因为事务成本低而随意合并的聚合在拆分后可能变成性能瓶颈单体中因为调用方便而松散关联的聚合在拆分后又可能变成分布式通信的负担。我见过一个支付系统拆服务时把“订单主单”和“订单支付记录”放进了同一个服务理由是它们都是订单域的。结果支付记录增长极快归档需求频繁主单服务每次发布都被数据量拖累最后不得不拆库拆表反而比当初正确划分边界多花了两倍工作量。3.2 聚合、限界上下文、微服务边界三者之间的真实关系初学者最容易混淆的一组概念就是聚合边界、限界上下文和微服务边界。我用一句话来区分聚合边界是数据一致性边界限界上下文是业务语言边界微服务边界是部署运维边界。三者有关联但绝对不等同。限界上下文是 DDD 战略设计里最重要的词它指一个明确边界内的业务模型和统一语言。同一个“客户”概念在销售上下文里关心的是联系方式、购买偏好和订单记录在风控上下文里关心的是黑名单状态、可疑行为记录、信用评分它们完全是两个不同模型。 试图让所有上下文共享同一个客户实体是典型的大型系统腐败点。正确的做法是让每个限界上下文自主建模上下文之间通过明确的接口通信。微服务边界应该天然追随限界上下文边界。一个限界上下文里的多个聚合如果业务关系紧密、数据访问模式相近、团队协作频繁完全可以放进一个微服务如果某个聚合演进速度极快、独立扩展需求突出也可以单独拆成服务。 我推荐的原则是“最小可行的服务最大必要的聚合”——一个服务至少包含一个聚合服务边界不打破聚合一致性多个聚合放进一个服务的前提是它们不会因为独立部署而频繁产生跨服务事务。举一个真实演进案例某零售系统最初的“商品上下文”里有商品基础信息聚合、商品价格聚合、商品库存聚合。上线后发现商品基础信息改动频率低但访问量巨大库存改动频率极高并发压力大价格聚合与促销上下文耦合紧密。后来团队把库存聚合拆成独立服务把价格聚合迁入促销上下文商品上下文只剩下基础信息聚合。三次改动都没有碰聚合内部的模型只是调整服务边界这正是“聚合稳定、服务灵活”的好处。3.3 事件驱动分布式系统下替代分布式事务的核心支撑分布式系统里如果目标不是“强一致”而是“最终一致”那事件驱动就是最常用的战术工具。核心思路是聚合在自己的事务边界内完成状态变更然后发布领域事件其他限界上下文订阅事件执行自己的本地更新。整个过程不出现跨库事务每个参与方都通过事件消息产生异步耦合。还是以订单和库存为例订单服务在确认订单的本地事务里落库订单状态同时发布 “OrderConfirmed” 事件。库存服务订阅到这个事件后在自己的数据库事务里扣减库存。这里有两个细节必须严格把控。第一事件发布和本地事务必须原子化。 否则会出现订单状态已提交但事件没发出去库存不扣超卖风险随之而来。常见方案是“本地消息表 消息队列”或者“事务性发件箱”先把事件落地到同库的表里再由后台任务或监听器转发到消息中间件。第二消费者必须按业务规则处理幂等。 消息队列虽然很多已经做到“至少一次”投递但消费端代码切换或网络异常仍可能收到重复事件库存扣减必须支持幂等重放。事件的选择也要谨慎。不是所有业务改动都值得发事件事件的价值在于通知“对别人有意义的事情”。订单确认事件有意义因为库存、支付、物流都关心订单状态字段从“A”改到“B”这种内部实现变化就不值得发事件。 事件命名要采用过去时用统一语言描述已经发生的事实比如 OrderConfirmed、PaymentReceived而不是 OrderStatusChanged 这种纯数据变化的说法。4. 分布式中台战略全景从战术工具到战略设计4.1 中台的本质为什么是共享能力域再造这几年“中台”这个词被滥用得厉害很多公司把中台理解成一个独立的项目组或者一堆被拆出来的公共服务。但从 DDD 的战略视角看中台的本质是跨多个业务线的共享能力域它是一个限界上下文的集合而不是一个技术平台。我判断中台建设是否成功的标准很简单业务方是否可以在不反复解释业务术语的情况下直接复用中台提供的领域能力。 如果业务方要调用中台的商品服务却还要向中台团队解释什么是“促销价”、什么是“阶梯价”那说明中台并没有形成自己的统一语言它只是一个技术包装过的共享数据库。那么中台能力从哪来它来自对多个业务线的共性提炼。比如订单中台要支撑电商、门店收银、B2B 批发、第三方代销就必须抽象出订货、履约、结算这些领域的共性模型同时让各业务线以扩展点方式承载差异性。 DDD 在这个过程中能提供的是清晰的上下文映射和各上下文间的接口治理而不是一个“自下而上把所有共性需求收集起来”的需求池。中台最怕的是做成需求收集器业务线提一个需求中台加一个功能最后中台变成一个大泥球谁都在用谁也改不动。在设计共享能力时有一条战略层面的通用规律共享的是能力不是数据所有权。 中台向业务线输出“商品查询能力”“库存扣减能力”但商品数据的归属仍然在中台上下文里业务线通过 API 或领域事件获得所需视图而不是直连中台数据库更不应该把自己的数据库和中台数据库做成同步复制。这样做会让中台退化成一个“中央数据仓库”领域逻辑反而无处安放。4.2 战略设计工具箱事件风暴与上下文映射分布式中台战略设计的起点不是画架构图而是先把业务事件梳理清楚。事件风暴就是这样一种轻量高互动的工作坊方法业务专家、架构师、开发人员围坐一起用彩色贴纸把领域事件、命令、聚合角色逐步贴到长墙上。整个过程非常直接——事件是橘色贴纸命令是蓝色贴纸聚合是黄色贴纸领域专家看到的是自己熟悉的“发生了什么”的语句技术人员看到的是模型和边界双方用同一种语言对话。我做过的有效事件风暴开场从来不问“你们系统有哪些模块”而是顺着一个端到端的业务旅程走用户下单时发生了什么系统支付时发生了什么物流发货时发生了什么 一条业务主线走完后再对每个事件追问谁触发了这个事件这个事件会导致什么后续事件哪些规则必须在这个事件发生前满足这种追问会自然暴露出聚合的雏形以及不同聚合之间的协作关系比闭门建模高效得多。事件风暴之后紧接着要做上下文映射。上下文映射的工具包括几种关系类型{% message_patterns %}合作关系、共享内核、客户-供应商、防腐层、开放主机服务。那些相互独立、通过事件或 API 集成的上下文通常用客户-供应商或开放主机服务的关系需要共享某些模型结构的则可能引入共享内核或合作关系。防腐层的角色尤为重要它的存在是为了保护一个新开发的上下文不受外部老旧系统或语义混乱系统的模型污染。 我在一个项目中负责的商品上下文要对接一个含义混乱的第三方库存系统就在边界处写了一个防腐层把第三方接口的磁盘参数、状态码全部翻译成本上下文专用的库存模型。防腐层内的翻译代码虽然琐碎但它确保了三方系统的混乱不会渗透到我们精心设计的领域模型里。4.3 战略设计绕不开的组织问题康威定律的映射DDD 战略设计如果只停留在图纸上落地时必然碰壁因为系统的最终形态一定是组织结构的缩影。康威定律说得很直白设计系统的组织其沟通结构往往会镜像到系统架构中。 中台要和多个业务线协作如果组织上中台团队以项目组机制独立运作业务线需求以瀑布方式排队那么中台与业务线之间一定会形成巨大的上下文鸿沟。所以战略设计里有一个 DDD 衍生出的重要实践——“限界上下文优先的组织架构”。 每一个限界上下文都应该有清晰的代码库归属和团队归属。反例是很多公司按照技术职能划分团队数据库组管所有数据模型后端组管所有业务核心前端组管所有接口交互。这会导致一个限界上下文内的领域逻辑被三个团队扯碎统一语言完全失效。正例是让一个全职能团队负责一个上下文前后端、测试、数据库都是团队内成员这个团队对业务模型和模型演进有完全控制权。我见过的最成功的中台实践是让中台以“能力域团队”方式运作每个能力域对应一个限界上下文能力域团队独立排期、独立发布、独立度量业务指标。中台不设一个庞大的统一组织而是由一个个专注共享能力的自治团队组成他们之间通过契约和事件协作而不是通过集团管理强行合并。这样做系统的边界才能真正稳定下来中台战略才可能从 PPT 变成经得起业务迭代考验的基础设施。4.4 战略设计中最容易翻车的地带分布式中台战略失败案例的共同点我总结下来有三个。第一把事件风暴变成一次性的年终团建。 事件风暴不是一次活动而是一个持续演进的建模循环。业务变化后事件风暴应该重新召集领域专家重新审视事件流和上下文边界。很多团队做完一次事件风暴就像交差一样后面模型腐化了也毫无知觉。正确的做法是把事件风暴做成每个迭代可重复进行的轻量流程至少每季度回顾一次上下文映射关系。第二上下文映射只画不执行。 很多人画完上下文映射图觉得自己已经完成了战略设计然后各团队照旧各写各的接口契约没有任何治理。上下文映射图的真正产出物不是图本身而是图中每个关系的明确协作协议谁是上游、谁是下游、接口版本如何演进、防腐层代码谁维护、事件发布和订阅的契约如何变更。这些协议如果没有落实到代码仓库、接口文档和团队工作协议里图就只是一张精美的废纸。第三试图一步到位建设大而全的中台。 中台建设最忌讳一开始就把所有业务线共性和差异一次性摸清然后规划一个宏观全景最后花一年时间实施。这个路径几乎必死因为业务机会和业务结构在一年内早就变了。可行的路径是先选一条价值最高的业务线做试点在试点中提炼出共享上下文形成基线模型再逐步扩展。 中台是从具体业务场景中长出来的不是从上而下的蓝图堆出来的。5. DDD 落地的路线图与速查表5.1 从 0 到 1 的推荐落地路线如果你所在团队正准备引入 DDD我会建议按下面五步走每一步都有明确的退出条件避免陷入无限讨论。第一步选一个被当前代码折磨得最厉害的业务模块而不是选一个最核心的模块。 被折磨的模块痛点明显团队有改变动力成功后的对比也更直观。第二步开展事件风暴工作坊产出事件流和初步聚合列表这一步最多安排两到三个半天。 第三步在单服务范围内完成战术落地把聚合模型映射到代码用六边形架构组织依赖方向跑通一个完整的用户故事。 第四步在同一业务域内尝试拆分服务边界引入事件驱动替换本 need 要在跨服务处使用的事务调用验证最终一致性链路。 第五步如果你所在组织有多个业务线共享能力的诉求再启动中台项目用事件风暴和上下文映射设计共享能力域按试点业务线逐步推广。每一步和下一步之间都有依赖关系我不建议跳步。 没做过战术落地就直接做中台战略设计很容易落入“纸面架构”的陷阱只做单服务战术而完全不考虑分布式边界则容易在系统拆分时重新陷入混乱。DDD 的价值不在于让你突然拥有某项神奇技能而在于让你从单点代码优化一路贯通到整个企业级系统的架构决策。5.2 常见问题排查速查表现象原因排查方向领域模型变成贫血模型业务规则被搬到 Service 层检查是否能不通过 Service 直接调用实体业务方法完成核心操作聚合频繁跨服务通信服务边界拆分过细重新审视哪些聚合属于同一限界上下文考虑合并服务分布式事务满天飞事件驱动替代不彻底梳理哪些一致性可以放宽为最终一致引入事件发布与订阅模型和表结构高度耦合表驱动建模暂时抛开表结构从用例和事件流重新建模业务方和开发方对概念理解不一致缺乏统一语言建立词汇表开发人员参与事件风暴使用业务术语命名代码事件风暴做完没有落地产物上下文映射与接口契约缺失明确每个上下文关系的协议、接口版本管理和防腐层归属中台服务被业务线绕过直接操作数据数据所有权失控明确共享能力的边界禁止直连中台数据库提供 API 作为唯一入口团队按技术职能划分DDD 推行阻力极大限界上下文没有对应团队边界推动组织向能力域团队演进至少先从代码库归属和接口团队归属入手这张表是我在各种项目里反复验证过的排查清单遇到问题先按行对号入座比重新翻阅 DDD 原书来得快。5.3 最后补一句给正在推进 DDD 的人我个人在实际操作中的体会是DDD 最反直觉的地方在于它看起来是一堆方法论但真正推进时卡点全部出现在沟通和协作上。 事件风暴的价值不是那张满是贴纸的照片而是领域专家、开发、测试在同一个房间里对业务达成共识的那几个小时。上下文映射的价值也不是那一张线框图而是让两个团队坐下来谈契约、谈协作协议、谈模型边界的那几个下午。如果你的组织连坐下来把业务聊清楚的意愿都没有DDD 的任何工具都帮不上忙。另外分享一个非常实用的小技巧在做战术落地时不要追求所有聚合都“纯净无依赖”过度设计反而会让代码难以落地。先用最朴素的代码把业务规则封装好让测试锁定核心行为然后随着你对领域的理解加深再逐步重构出更适合当前业务形态的聚合边界。 DDD 是迭代出来的不是设计出来的。这也是我从大量实战项目中得到的最终结论——认知升级永远是一个过程而不是一次顿悟。
