5.3 全程复盘：订单域从事件风暴到上线
5.3 全程复盘：订单域从事件风暴到上线
本节摘要：前面章节的每一个方法都单独演练过，本节把它们拼回时间线：青柚商城订单域从立项、事件风暴、建模冲刺、动工迁移到灰度上线、大促验证，整整二十二周的真实历程。每个阶段交代目标、动作、指标与教训，最后给出这套复盘方法的变式——项目过半才引入 DDD 的团队该怎么补课。
背景与起点
复盘从立项文书上的三行字开始：目标——把"规则理解不一致"类事故的月均发生数从 2.3 次降到 0.5 次以内；范围——交易上下文及其与营销、仓储、财务的协作边界，不含物流（第三方承运，走防腐层渐进接入）；周期——两个季度。三行里最值得学的是范围：立项时刻意排除了物流，因为它属于外部系统，谈判对手不在公司内部。早期 DDD 失败常见于把"全部重构"当目标，战线一长，业务方先失去耐心。
当时手里的家底：1.4 的对照实验结论（说服了技术团队）、2.3 的评估表总分 23（说服了管理层）、事故复盘记录（说服了业务方）。三种人要三份不同的证据，这是立项阶段的全部技巧——给管理层看成本账，给业务方看事故账，给技术团队看写法账。
二十二周时间线
各阶段的目标、动作与教训
第 1–2 周，立项取证。动作：评估表打分、事故账整理、三场汇报。指标：立项文书获批。教训：先劝退了行政系统团队（2.3 的案例），让管理层看到有尺子，比任何 PPT 都快地建立了信任。
第 3 周，事件风暴。动作：5.1 那场工作坊，外加一场仅六人的补充场（补铺财务与退款线）。产出：六十七条事件、九个痛点、四个边界候选圈。教训：补充场开晚了——财务线的主场景在工作坊主场上只铺了十分钟，导致第 4 周又回头补了一次谈判。业务线越多，第一场工作坊越该拆成两场，别指望一场铺完。
第 4–9 周，建模冲刺。这是谈判最密集的六周：每周两轮谈判会，一轮对业务（规则确认），一轮对技术（模型落地）。关键产出按序：词汇表第一版与仲裁机制（第 4 周）；上下文地图定稿（第 5 周）；交易上下文聚合划分，含 3.5 那道库存争议的结论（第 6 周）；与营销、财务的协作条约——防腐层加发布语言（第 7 周）；第 8–9 周用 5.2 的双向循环把三条核心规则链路（下单计价、取消、退款分摊）落成了可演示的代码。指标：三条链路的演示各获得业务方签字确认。教训：第 5 周地图差点为"优惠券归属"翻盘重画——营销一度主张券是资产应独立成上下文，最后靠 2.3 的判据（券的规则独特性在叠加策略，归营销；券的使用事实归交易）才收口。谈判僵局的标准解法是把争议拆成两个命题分别归位，而不是争谁吞下谁。
第 10–17 周，动工迁移。最累的八周，也是计划里写得最粗的八周——事后复盘公认这是最大的预估失误。动作三线并行：新聚合按第 3 章落地；旧 Service 的规则按"搬家清单"逐条迁入聚合（4.1 的假四层治理就在这一步）；新旧系统双轨并行，读走新写走旧，按场景逐步切换写。指标：迁移动了四十一条规则、切了九个写场景。教训：双轨期每天的核对对账花了专职一人周——迁移预算里必须给"对账"单独立项，它不是测试的附属品，是切换期间最重要的安全网。
第 18–20 周，灰度上线。按场景切流：先切"未支付订单取消"（影响面最小、补偿最简单），再切下单计价，最后切退款。每切一个场景观察七十二小时，指标是事件对账差异率与客服工单量。教训：第一个场景就抓到一个灰度bug——赠品行的分摊份额没进事件报文，对账差异率跳到 0.4%，回滚、修复、重切。先切"可退出的场景"这个顺序保了命：如果先切退款，同样是这个 bug，资金影响会放大一个量级。
第 21–22 周，大促验证。一次中等规模大促。结果：规则类事故零发生；单次规则变更（门槛调整）的波及面从平均 3.4 个系统降至 1 处配置；规则类需求从需求到上线的平均周期从十一天缩到四天。代价也要如实记：营销、交易、仓储三团队合计投入约 4.5 人月，超原预估两成——超支全部在迁移期。
解读：时间都花在了哪
把二十二周按产出归类：真正的编码约占四成，谈判与建模约三成，双轨对账与切换占两成，培训与文档一成。两个解读值得带走。其一，谈判集中在建模冲刺期而非动工期——边界谈透之后，编码期的技术争议显著少于历史项目，代码期安静得反常。很多团队把 DDD 想象成"写代码的新姿势"，这个时间分布说明它首先是谈判的时间重新分布。其二，超支的两成与事故归零是同一枚硬币：迁移期的对账人力买的就是切换期的胆量，这笔钱省不得。
指标是怎么定下来的
复盘常被质疑的一点是指标的选择——为什么是这三个数，而不是代码行数、测试覆盖率、领域模型文档页数？立项时有过一轮争论，结论值得记录。代码类指标全部被否：行数奖励冗长，覆盖率在双轨期会失真（新旧两套都在跑，覆盖率高只说明重复多）。留下的三个指标有一个共同点：它们都度量谈判的产出，而不是编码的产出。事故频次度量语言是否统一（2.1 的词汇表有没有生效），波及面度量边界是否划对（2.2 的地图有没有划在关节上），需求周期度量整条链路的顺畅程度。5.3 想留给读者的一般化结论是：建模协作类项目的度量，应该挑那些"谈判失败时必然恶化"的指标——这样指标才会逼着团队回到谈判桌上，而不是逼着团队优化报表。
变式：项目过半才引入 DDD 怎么办
青柚的时间线从立项开始，多数团队没有这个奢侈。项目过半才引入时，复盘框架给出三个修正。第一，跳过全面取证，用一次事故做楔子：挑最近一次规则类事故开复盘会，会上直接铺事件时间线——事故是最强的谈判筹码。第二，不求迁移只求止血：不为存量代码做全面搬家，新规则一律按新模型落进新聚合，存量规则碰到哪个搬哪个，用 5.2 的"规则搬家"节奏自然演化。第三，把二十二周压缩成"三加一"：三次谈判（边界、词汇、协作条约）加一次事件风暴，两周内完成——半途项目的业务方还在场上，趁热打铁比从容布局更重要。
带走的判断
- 立项三要素：可度量的目标、刻意收窄的范围、分人下菜的三份证据。
- 时间分布的真相：谈判集中在建模期，编码期安静；迁移期最费命的是双轨对账，预算要单独立项。
- 灰度按"可退出的场景"排序，第一个被抓的 bug 决定了你对整个迁移的信心。
- 半途引入 DDD 的三修正：事故当楔子、只止血不搬家、三加一压缩节奏。
到这里，订单域的主线故事全部讲完。第 6 章上强度：CQRS、事件溯源、遗留系统、Saga——四门进阶手艺，解决的都是前五章刻意绕开的硬骨头。