lnstagram优选在动手写这篇总结之前，我先说句实话：DDD（领域驱动设计）不是银弹，但你如果被“业务规则越来越多，代码越写越乱，改一个需求恨不得牵连七八个 Service”这种情况折磨过，那它值得你静下心研究一次。我在两个中大型项目里完整落地过 DDD，第一次踩坑踩到怀疑人生，第二次才慢慢摸到门道。今天这篇不谈教科书上的概念搬运，只聊我在实战中的思考、选型理由、落地步骤，以及那些文档里根本不会写的坑。
这篇文章适合谁？不是刚入行的新人，而是已经在 CRUD 里泡了很久、手里捏着几个复杂业务模块、隐约觉得“现在这种写法不可持续”的后端开发。也适合那些正准备用 DDD 重构老系统、或者要把单体按业务能力拆成微服务的团队。我会从“为什么需要 DDD”讲起，到战略设计、战术设计、代码落地，最后聊一聊那些让人头大的实际问题和我的应对办法。
1. 为什么要做 DDD：从代码坏味道说起
1.1 我遇到的真实业务复杂度困境
事情要从 2019 年我接手的一个营销系统说起。这个系统负责整个公司的优惠券、满减活动、积分兑换、用户标签等一堆业务。刚接手的时候，代码已经跑了三年，按传统三层架构写的：Controller → Service → DAO。乍一看结构挺清晰，但真的动手改需求就发现，所有业务逻辑全堆在 Service 里，一个订单结算的 Service 方法有六百多行，里面混杂了优惠计算、库存扣减、积分累加、短信通知，甚至还有折扣码校验。
最要命的是，产品经理提需求从来不按“模块”提，而是按“场景”提。比如“大促期间，用户下单时如果使用了优惠券，且商品在秒杀活动里，则积分按原价计算”。这种需求落到现有代码里，你根本不知道该改哪个 Service，因为优惠逻辑既在订单 Service 里出现，又在优惠券 Service 里有，还和商品模块耦合在一起。改一个地方，另一个地方就出 bug，线上事故接连不断。
这就是典型的业务复杂度失控。业务规则本身并不算天文数字级的复杂，但代码结构没有跟着业务边界走，导致复杂度被无序地扩散到所有层。我当时做过一次统计：优惠相关逻辑散落在 23 个 Service 方法里，没有任何一个类是完整的“优惠上下文”。
1.2 DDD 不是一套 API 写法，而是思维方式切换
很多团队对 DDD 有个误解，以为“按包结构分成 controller/service/domain/infrastructure 四层就算 DDD 了”。这种认知害了不少人。真正的 DDD，第一步不是写代码，而是切换思考方式：从“数据库表怎么设计”转向“业务领域怎么建模”。
传统开发流程是：先看需求 → 设计数据库表 → 写增删改查。这种流程下，数据库成了系统的核心，业务逻辑反而被表结构牵着鼻子走。表设计得好，代码就少踩坑；表设计得烂，业务代码就是戴着镣铐跳舞。而 DDD 的核心思维是：领域模型才是系统的核心，数据库、缓存、消息队列、RPC 协议这些东西统统是基础设施，应当为领域模型服务，而不是反过来。
我打一个生活化比方。传统开发像是按房间功能买家具，先定了每个房间放什么，然后家具只能迁就房间格局；DDD 则是先弄清楚一家人怎么生活，再决定客厅、厨房、书房怎么划分，最后才挑合适的家具。家具（表结构、缓存、接口协议）不合适可以换，但生活动线（业务逻辑）不能被家具绑定。
这个思维一旦转过弯来，你会发现很多之前“改不动”的代码，根源根本不是技术选型问题，而是模型和业务脱节了。贫血模型（实体只有 getter/setter，逻辑全在 Service）之所以如此普遍，就是因为开发者脑子里先有“表”再有“对象”，对象只是表的映射，自然存不住业务规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 战略设计：先画边界，再写代码
2.1 限界上下文怎么划分：我的一套实操方法
战略设计是 DDD 的第一大块，核心产出物就是限界上下文的划分。限界上下文说白了，就是“模型的有效边界”。同一个“用户”概念，在订单上下文里关注的是收件人和支付信息，在风控上下文里关注的是历史行为和信用分，在营销上下文里关注的是标签和等级。没有边界，所有人共用一套 User 类，结果就是每个需求都要兼容所有场景，类越来越臃肿，谁都不敢动。
我划分限界上下文最常用的方法，是找“业务动词”而不是“业务名词”。名词是容易误导人的，比如“订单”，订单管理是一个上下文，订单履约又是另一个上下文，订单售后还是另一个。但如果你去看业务动词——下单、支付、发货、退款——每个动词背后都对应一套独立的业务规则、独立的生命周期、独立的干系人。
实操时我建议从这三个角度切：
- 看变化频率：一段业务规则如果经常变（比如促销策略），而另一段很少变（比如订单状态流转），它们大概率是两个上下文。
- 看团队组织：康威定律在这里特别灵验——通常一个稳定的团队只会维护一个核心上下文，跨团队的调用会自然形成 API 边界。
- 看数据归属：问一个问题，“这个数据到底该由谁负责修改？”如果两个模块都要改同一份数据，往往意味着边界画错了。
拿我做的营销系统举例，我最终把“优惠计算”从“订单处理”里拆了出来，形成独立的优惠上下文。订单上下文只管订单本身的创建、状态流转，优惠上下文负责算价和核销。两个上下文之间通过“请求优惠计算并返回结果”这样的方式交互，订单不再依赖任何优惠的表结构。
2.2 通用语言：每个上下文都要有自己的黑话
通用语言这个概念，听起来简单，做起来最难。它是领域专家和开发团队之间共享的一套术语，每个术语的含义在同一个上下文内有且只有一个。
我见过最典型的问题就是“客户”这个词。市场部说客户是指“留过手机号的潜在用户”，销售部说客户是指“已经签过合同的正式客户”，客服部说客户是指“所有提交过工单的人”。如果开发的模型里只有一个 Customer 表，那必然顾此失彼。DDD 的做法是，在“售前线索上下文”里叫 Prospect，在“合同管理上下文”里叫 Account，各管各的，通过防腐层做翻译和转换。
创建通用语言不能光靠开会。我的经验是，每次需求评审会上，凡是大家用词不一致的地方，都要当场敲定，写进项目的 glossary 里。这个 glossary 不是摆设，它要成为代码命名、接口字段命名、数据库表名、甚至 Git 分支命名和 PR 描述的参考依据。我在项目里就吃过亏：模型叫 Reward 而数据库表叫 coupon_info，对接的同事翻半天代码才搞明白是同一个东西。
2.3 上下文映射关系：防腐层到底防的是什么
限界上下文划分完之后，上下文之间会有各种关系：共享内核、客户-供应商、防腐层、开放主机服务、发布语言，等等。对大部分项目来说，最实用、最值得投入的是防腐层（Anti-Corruption Layer）。
防腐层的目的是防止外部模型的“坏味道”污染自己的领域模型。比如你的订单上下文对接物流系统，物流系统返回值里有一个 status 字段，可能取值 delivered、pending、failed。但你的订单系统内部对履约状态的定义要更丰富。如果你直接在订单代码里引用了物流的 status，那么物流改枚举值，你的代码就要跟着变——这就是污染。
防腐层的做法是在自己的上下文边界处建一层转换器，把外部 DTO 翻译成自己领域的内部模型。这层转换器可以放在 infrastructure 层，用 adapter 模式实现。我一般习惯为每个外部依赖建一个 adapter 接口，比如 LogisticsGateway，内部实现里做字段映射和异常转换。这样做之后，外部系统怎么改，项目里只需要动 adapter 一个文件，领域层永远不需要 import 任何外部 DTO。
3. 战术设计：核心模型到底怎么落到代码
3.1 实体、值对象、聚合：区分它们的三条铁律
战术设计是 DDD 的第二大块，也是代码层面最终能落地的那部分。在战术设计里，最基础的概念是实体（Entity）和值对象（Value Object），这两个概念很多开发者会混淆，我教你一个最简单的判断方法：
一个对象有没有连续的生命周期标识？有，就是实体；没有，就是值对象。
举个例子，“订单”是实体，因为订单有订单号，从创建到完成，它的身份一直不变，哪怕里面的商品明细改了，订单还是那笔订单。“地址”是值对象，因为一栋建筑换了个门牌号，描述地址的那个对象就变了，它没有固定身份，只要属性值相同，两个地址对象就是“同一个”。值对象还有个重要的特性：不可变。你在代码里任何时候都不应该 modify 一个值对象的属性，只能通过构造新对象来替换。
聚合（Aggregate）是一组相关对象的集合，聚合根是外部访问的唯一入口。这个设计的目的，是保证数据一致性和业务不变量。
有一次，我在项目里设计“促销活动”聚合，活动下有多个规则，每条规则又可以配置多个条件。如果让外部直接操作活动和规则，很容易出现“规则 A 被删了但活动还在引用”这种不一致。用聚合的方式，所有对规则的修改都必须通过 Activity 聚合根来完成，比如 activity.updateRule(ruleId, newContent)，聚合根内部保证规则不能脱离活动存在。
聚合边界怎么划最合理？我总结一句话：事务边界就是聚合边界。如果一个操作必须要保证 ACID，那它就应该落在同一个聚合里。如果一个操作只是“最终一致”就行，那就可以拆成两个聚合，用领域事件来协调。
3.2 聚合设计最容易犯的两个错误
聚合设计是 DDD 战术部分最难的环节，我在实战中经常看到两种相反的极端。
第一种是聚合根设计得过大。一个订单聚合里放了订单头、订单行、收货地址、支付记录、发票信息、售后记录……看起来“全”，实际上每次加载订单都要把一大堆数据读出来，性能极差，并发修改也很容易冲突。这种大聚合本质上就是把所有业务逻辑用一棵对象树包起来，违背了聚合边界要尽量小的原则。
第二种是聚合根设计得过小，甚至退化到和数据库表一一对应。订单一个聚合，订单明细一个聚合，支付记录又是一个聚合。这样的话，域模型和表结构没有区别，聚合规则形同虚设，事务还得靠分布式事务去跨聚合补偿，复杂度比做大聚合还高。
我现在的设计心法是：先找业务不变量，再反推聚合边界。问自己一个问题：“哪些变化必须像原子操作一样要么全部发生、要么全部不发生？”像订单金额必然等于商品金额之和这种约束，才是聚合存在的基础。这个约束想清楚之后，聚合的边界就水到渠成了。
3.3 领域服务与领域事件：不能把所有逻辑都塞进实体
实体和值对象承载了一部分业务逻辑，但总有一些逻辑不属于任何一个实体。比如“计算用户最终的优惠金额”，它涉及用户、订单、优惠券、活动四种对象，如果放在任何一个对象里都不合适。这时候就要用到领域服务（Domain Service）。
判断一个逻辑该不该放领域服务的标准，我自己的经验是：如果这个逻辑需要协调多个聚合，或者需要访问外部资源（比如调用一个规则引擎），并且它不是某个聚合的固有行为，那它就是一个领域服务。领域服务在代码里的位置很特殊，它不持有状态，只是协调和计算，所以设计得好的领域服务通常都是无状态的。
领域事件（Domain Event）则是另一个工具。当一个聚合发生变化，而其他聚合需要感知这种变化时，不要同步去调用对方的方法，而是发布一个事件，让订阅方自己处理。订单支付成功之后要通知积分、通知库存、通知物流，如果直接写代码串行调用，每次加一个下游需求就要改订单代码。用领域事件，订单上下文只管发布“订单已支付”事件，其他上下文各自订阅，互不干涉。
我用领域事件解决过很经典的“死循环”问题。之前订单和库存耦合在一起，库存扣减失败要回滚订单。后来库存上下文独立出去之后，订单发“已下单”事件，库存消费事件后扣库存，如果库存不足，发布“库存不足”事件，订单订阅后再把订单置为已取消。两个上下文完全解耦，而且整个流程可以从事件日志里完整回溯，排查问题比之前看那一堆 try-catch 舒服太多了。
4. 实操过程：从事件风暴到第一个聚合完整落地
4.1 事件风暴工作坊：两小时摸清核心链路
如果你已经决定在一个项目里实践 DDD，我强烈建议从事件风暴（Event Storming）开始。这是我用过的最有效、最低成本的业务梳理方法。
事件风暴的玩法很简单：找一间会议室（或一个线上白板），准备几种颜色的便利贴，把业务上的关键人都拉进来——产品经理、业务专家、开发负责人、测试负责人。我们用一个真实的电商例子来演示流程：
第一步，所有人一起写出“业务里会发生的事件”，每个事件用红色便利贴写一句话，格式是“过去时”的动词短语，比如“订单已创建”“支付已完成”“库存已扣减”“退款已发起”。这一步不讨论实现，也不争论定义，只写事实。
第二步，把事件按时间顺序排成一条大致的流水线。你会看到很多事件之间存在明显的聚集——有的发生在“下单”阶段，有的发生在“履约”阶段，有的发生在“售后”阶段。这些聚集，就是限界上下文的雏形。
第三步，为每个事件找出“是什么触发了它”和“它导致了什么”，把触发和执行动作也贴出来。这一步会暴露很多之前没人注意的隐式规则，比如“订单支付完成后，如果商品是虚拟商品，则自动发货”——这个规则很可能散落在代码的某个 if 分支里，在这次讨论中才第一次被所有人看见。
第四步，给每个关键事件补充“由谁来执行”，用黄色便利贴写上“用户”“客服”“系统定时任务”等角色。当同一个事件既有用户角色又有系统角色时，就要警惕这个流程是否隐含了不同的上下文。
我带着团队做了一次 3 小时的事件风暴，把原来混乱的“订单系统”理成了订单、支付、履约、积分、优惠五个上下文。之前每次迭代都要谨慎评估“改这里会不会影响那里”，现在各团队只在自己上下文里改代码，跨上下文改动必须走接口变更评审，回归范围一下子缩小了很多。
4.2 工程结构搭建：按上下文分包，而不是按技术分层分包
很多团队落地 DDD 的最大阻力不在于概念理解，而在于工程结构不好落地。Maven/Gradle 项目里如果还是按照 controller/service/mapper 分包，那领域模型一定会被技术层的依赖拖垮。
我目前在项目里使用的结构是这样的（以订单上下文为例）：
text复制order-context/
├── order-api/ # 对外暴露的接口和 DTO
├── order-app/ # 应用层：用例编排、事务管理、权限校验
├── order-domain/ # 领域层：实体、值对象、聚合根、领域服务、领域事件
│ ├── model/
│ │ ├── Order.java
│ │ ├── OrderLine.java
│ │ ├── OrderStatus.java
│ │ └── ShippingAddress.java
│ ├── service/
│ │ └── OrderPricingService.java
│ └── event/
│ └── OrderPaidEvent.java
├── order-infrastructure/ # 基础设施层：数据库操作、RPC 调用、消息发送
│ ├── repository/
│ ├── adapter/
│ └── converter/
└── order-start/ # 启动入口和配置
这里有三个关键设计心得：
第一，域名层不依赖任何 Spring 注解。Order 类里不应该出现 @Entity、@Table 这样的 JPA 注解，也不应该出现 @Component。领域层是纯 Java 对象，唯一依赖是你自己定义的 Repository 接口。这样做的最大好处是，将来要换技术栈（从 MyBatis 换到 JPA，从 RPC 换到 REST），领域层完全不用动。
第二，应用层只做编排。一个用例一个 Service 方法，比如 PlaceOrderService.placeOrder()，它做的事情是：调用仓库查询、调用领域服务计算、调用聚合根执行业务操作、保存聚合、发布领域事件。真正的业务规则都落在 Order 聚合根内部，应用层是一个“透明”的流程协调者，不应该有任何 if-else 业务判断。
第三，基础设施层实现领域层定义的接口。OrderRepository 是 domain 包里的接口，JpaOrderRepository 是 infrastructure 里的实现。依赖方向永远是 infrastructure → domain，这样领域层永远是清洁的。
4.3 一个简单聚合的代码示例：从模型到 Repository
理论讲再多也不如看代码直观。我还是用订单的例子，演示一下核心代码怎么写。
先看聚合根 Order：
java复制public class Order {
private OrderId id;
private UserId userId;
private List<OrderLine> lines;
private OrderStatus status;
private Money totalAmount;
// 创建订单：应用层调用
public static Order create(OrderId id, UserId userId, List<OrderLine> lines) {
// 业务不变量：订单必须至少包含一条商品
if (lines == null || lines.isEmpty()) {
throw new InvalidOrderException("订单必须包含商品");
}
Money total = lines.stream()
.map(OrderLine::getSubtotal)
.reduce(Money.ZERO, Money::add);
return new Order(id, userId, lines, OrderStatus.CREATED, total);
}
// 支付成功：这不是 setter，而是领域行为
public void markPaid() {
if (status != OrderStatus.CREATED) {
throw new IllegalStateException("只有新建订单可以标记为已支付");
}
this.status = OrderStatus.PAID;
}
public void addLine(OrderLine line) {
// 已支付订单不允许修改商品
if (status != OrderStatus.CREATED) {
throw new IllegalStateException("订单已激活，无法修改商品");
}
this.lines.add(line);
this.totalAmount = totalAmount.add(line.getSubtotal());
}
public boolean isPaid() {
return status == OrderStatus.PAID;
}
}
注意 markPaid() 和 addLine() 里都有状态校验，这就是把业务规则封装在聚合根内部的体现。如果用传统的 setter 方式，调用方完全可以在已支付的订单上继续加商品，规则只会零星地散落在各个 Service 方法里，早晚漏掉。
再看仓库接口的定义：
java复制public interface OrderRepository {
Order findById(OrderId id);
void save(Order order);
void delete(OrderId id);
}
这个接口定义在 domain 包里，基础设施层的 JpaOrderRepository 负责实现。领域层用的是 OrderId 这种值对象而不是 Long，从方法签名上就杜绝了“随便传个 id 就能查订单”的问题。值对象的好处在这里体现得淋漓尽致：它把“订单 ID 必须满足什么格式、不能为空”这些规则封装在对象创建时，而不是散落在各种调用方代码里。
5. 真实项目里最常见的坑：每个我都踩过
5.1 贫血模型是怎么被“养”出来的
说是坑，不如说是一个普遍现象。很多团队嘴上说用 DDD，结果代码写出来还是贫血模型——实体里全是 getter/setter，没有任何行为逻辑，所有业务判断都在 Service 里。我接手过这样的“伪 DDD 项目”，代码结构确实是四层，但领域层形同虚设。
贫血模型为什么这么根深蒂固？我认为根本原因是开发者的“数据库思维”惯性太强。拿到需求第一反应永远是“要加哪些字段、要不要建新表”，而不是“这个业务行为的规则本质是什么、应该由哪个对象来承担”。
要打破这个惯性，我的做法是代码 review 时盯着实体类看。如果一个实体类超过 80% 的方法是 getter/setter，那这个实体大概率是贫血的。接着我会要求开发者把所有涉及这个实体的业务规则列出来，然后逐个问：“这条规则放在 Controller 里合适吗？放在 Service 里合适吗？还是放在实体里更内聚？”绝大多数规则，最终会发现放在实体里才是低耦合的。这个过程一开始会很慢，但坚持两个迭代之后，团队会逐渐养成“先想行为、再想字段”的习惯。
5.2 过度设计：战略性项目也架不住为了 DDD 而 DDD
与贫血模型相反的另一端是过度设计。有的团队落 DDD 时恨不得把所有概念都用上，一个写用户登录的小接口也要设计个值对象、弄个领域事件、再来个组装层。结果代码量翻了三倍，业务逻辑一点没多，徒增维护成本。
我自己对“哪些模块适合 DDD”有一把尺子：核心域（Core Domain）优先用 DDD，支撑子域（Supporting Subdomain）和通用子域（Generic Subdomain）用传统 CRUD 就行。核心域是什么？是公司业务最差异化、最复杂、最值得投入的部分。对电商来说是交易和价格计算，对内容平台来说是推荐和审核，对 SaaS 来说是权限和计费。这些模块值得用 DDD 去精细建模，因为它们的复杂度会持续增长。而像短信通知、文件上传、邮件发送这种模块，CRUD 就够了，强行引入 DDD 只是自嗨。
还要注意，DDD 的建模是一个持续迭代的过程，不是在项目启动时一次性画完。我见过不少团队前两周疯狂做事件风暴，产出几百个事件，后面验收一审查发现一半事件对应的流程已经变了。模型与业务脱节，比没有模型更危险，因为大家会盲目信任它。正确的方式是把建模融入迭代节奏，每个 sprint 都留一点时间更新上下文映射和聚合设计。
5.3 性能与事务的妥协：DDD 模型也要向现实低头
DDD 模型设计得漂亮，但落地时总是会遇到性能问题和事务问题，这时候必须学会妥协。
第一个问题是聚合加载的性能。如果订单聚合里塞了十几条订单行、每行又有图片、标签、备注等信息，加载一整个订单就是一堆 SQL。我早期项目里就吃过这个亏，列表页查询直接 N+1，把服务打挂了。后来加了一层“读模型”方案：查询列表时走专门优化的查询通道，返回扁平 DTO，不经过聚合根；只有执行操作命令时才加载完整的聚合。这就是 CQRS（命令查询职责分离）的基本思路，不一定全套落地，但“写操作走模型、读操作走查询”这个原则强烈推荐。
第二个问题是跨聚合事务。传统单库事务里，订单和库存一起扣减是一条事务搞定的事。但分成两个聚合之后，各自维护一致性，就需要分布式事务或者事件驱动的最终一致性。我的建议是：能不拆就不拆，能最终一致就用事件，尽量别引入强一致分布式事务。前面说过订单库存的例子，一个“库存不足”事件就能解决的问题，不该用 TCC 这种重量级方案去扛。实际业务里，绝大多数一致性需求其实都接受秒级甚至分钟级的延迟，跑一个定时对账任务补漏，比在代码里做分布式事务要省心得多。
5.4 团队协作现实：技术方案需要“翻译官”
最后补一个非技术坑。DDD 落地最大的阻力不是代码，而是团队里总有人觉得“搞 DDD 就是浪费时间”。我遇到过业务分析师说自己没时间参加事件风暴，也遇到过老工程师说“原来的写法五年了也没出大问题”。
我的应对策略是找一个“翻译官”，就是团队里既懂业务又懂技术的人。这个人要能做业务语言和代码模型之间的桥梁：产品经理说“大促期间满 300 减 50 且可叠加店铺券”，这个人能立刻反应出这是优惠上下文里的规则对象模型，然后评估需要改哪些聚合。没有这个角色，DDD 战略设计和战术设计之间就会出现巨大的鸿沟，模型图画得再好也落不了地。
如果你决定要带团队实践 DDD，我建议先拿一个中等复杂度的业务模块做试点，不要一上来就全面铺开。等团队把 DDD 的思考方式内化之后，再逐步扩大范围。试点模块选得好不好，直接决定你这次改造是大家眼中的“成功经验”还是“失败教训”。
6. DDD 与微服务：黄金搭档还是有待商榷的组合
6.1 微服务拆分：以限界上下文为单位才有生命力
聊 DDD 就绕不开微服务，因为很多人正是想拆分微服务才开始学 DDD 的。二者确实有天然的契合：限界上下文从业务视角划定了系统边界，微服务则从部署视角决定了运维单元。如果微服务拆分不以限界上下文为依据，而是按照技术层（网关微服务、业务微服务、数据微服务）来拆，等于把一个业务逻辑完整的东西强行切成几段，服务间调用链又长又难排查。
我经历过一个反面案例：某个团队把“订单模块”拆成了“订单查询微服务”和“订单管理微服务”，数据库是同一张订单表，高峰期两个服务同时抢同一条数据，锁冲突不断。这就是典型的按操作拆服务而不是按业务拆服务。如果当时先做事件风暴，识别出“订单管理”和“订单分析”是两个不同的限界上下文，拆出来的服务边界就会清晰得多：一个负责订单状态流转，一个负责订单数据报表，二者不共享表结构，分析服务通过订阅订单事件来构建自己的只读数据。
DDD 给微服务带来的最大价值不是某个代码模式，而是做拆分决策时有了依据。没有 DDD，微服务拆分就是拍脑袋；有了 DDD，拆分方案背后是业务边界的推理过程。
6.2 数据一致性与分布式事务的现实解法
当你按限界上下文拆了微服务，原本单体里的一条数据库事务，现在变成了跨服务调用。这是最让团队头疼的落差：DDD 教你把聚合做小，但现实事务要求你在更广的范围内保持一致。
我常用的方案是“事务性发件箱”（Transactional Outbox）模式。逻辑不复杂：在业务数据库里建一张 outbox 表，和业务数据在同一个本地事务里写入。比如支付成功时，聚合根状态更新和“订单已支付”事件同时落库——因为在同一个事务里，要么都成功要么都失败。后台有一个定时任务（或者用 CDC 工具监听 binlog），把 outbox 里的事件投递到消息队列。下游服务消费事件后做自己的处理，整个链路是异步的，但不会丢消息。
这个方案比直接调 MQ 发送要可靠得多。我见过太多“先更新数据库再发 MQ”的代码崩溃在“数据库更新成功但 MQ 发送失败”这个点，然后就陷入了“对账”“补单”的泥潭。发件箱模式把消息可靠性和业务数据绑定在一起，从根上解决了这个痛点。
当然，发件箱模式也带来了新的复杂度：消息可能会有重复，消费者需要幂等。幂等怎么做？最实用的方法是在每个消费端维护一张“已处理事件表”，记录事件的唯一 ID；处理前先查重，处理后在同一个事务里更新已处理状态。这样虽然多了几行代码，但换来了系统的最终一致性，对于大多数电商业务来说完全够用。
6.3 模块化单体：不上微服务也能用 DDD
最后说一个经常被忽略的点。DDD 的落地并不强制要求微服务架构。如果你的系统还是单体应用，团队也只有两三个后端人员，完全可以做“模块化单体”（Modular Monolith）：一个代码仓库，一个部署单元，但内部按限界上下文划分清晰的模块边界，模块之间只能调用公开接口，不能直接访问内部模型。
模块化单体是 DDD 落地初期性价比最高的形态。它保留了单体架构的运维简单和事务便利，又用模块边界隔离了业务复杂性。等未来某个上下文确实遭遇了独立的扩容需求、独立的发布节奏要求，再把这个模块拆出去变成微服务，改造路径也很顺。相反，一上来就拆微服务的团队，几乎没有不后悔的：服务治理的复杂度会迅速吞掉业务建模带来的收益。
我现在的原则是：单体优先，模块化拆分，DDD 建模；只有当监控数据显示某个上下文自身确实成为性能瓶颈或发布瓶颈时，才考虑物理拆分为微服务。
写在最后：DDD 落地三年后的真实感受
回头看看，我实践 DDD 的这三年里，真正让我坚持下来的不是某个方法论本身，而是它带给团队的那种“业务和代码对齐”的感觉。每次产品经理提需求，我能很快说出“这个改动要落在哪个上下文、动哪个聚合根、哪些下游需要订阅什么事件”——这种确定性，在以前那些 Controller 巨无霸项目里是完全不敢想象的。
但我也必须提醒你，DDD 的学习曲线真的不低，团队里至少要有一个人能扛住最初的建模压力和概念清洗。如果有条件，找一个真正落地过 DDD 的人做顾问，比自己啃书快得多。从一个小模块开始，先做事件风暴，再建模，再写代码，跑通一个完整闭环之后，你自然能判断这个方法论适不适合你的团队。
如果你问我“要不要上 DDD”，我的回答从来都是：先看看你的业务是否足够复杂。复杂到你觉得现状快不可控了，那就去试，它不会辜负你；如果业务本身很标准，CRUD 两三行能写完，那 DDD 就留到以后再说吧。