7.2 常见误区与陷阱清单

7.2 常见误区与陷阱清单

本节摘要：本节收集青柚商城三条业务线一年推广里真实踩过的十个误区，每个按"症状—根因—纠正"三段展开，并标注它在全书对应的判据。清单的用法不是读完记住，而是每季度拿它给自己的项目做一次体检——误区从不因为聪明而绕开人，只会因为判据而绕开人。

一个反例开场

最应该引以为戒的误区，来自推广最顺利的阶段。营销线热情最高，立项书里写着"采用 DDD 最佳实践，建设优惠券领域超级模型"，两个月后交付了一套包含十四个聚合、四十七个领域事件的"完整 DDD 架构"——然后优惠券叠加规则照旧散在三个地方，因为这个"超级模型"是照着数据库表关系画的，每张表一个聚合。热情、预算、人力全都在场，唯独判据不在——这个案例排在清单第一个，因为它证明误区与团队水平无关，只与流程里有没有那把尺子有关。

十误区地图：按出错环节分布

认知误区：还没动手就错了

误区一：把 DDD 当分层规范。症状：立项书写"采用 DDD 分层架构"，落地只剩 domain 目录改名。根因：把手段当成了目的——四层只是给知识安家的脚手架，核心主张"模型是核心资产"被丢了。纠正：立项书里必须出现可度量的业务目标（事故率、波及面），出现不了就还不是 DDD 立项。对应判据：1.2 的资产三判据。

误区二：为微服务而划上下文。症状：先定了"今年拆八个微服务"的指标，再倒推找边界。根因：把部署决策放在了设计判断前面——2.2 说上下文是发现语言分岔后的设计，指标倒推出来的边界没有语言依据。纠正：上下文地图完成后先跑模块化单体半年，让边界自己证明自己。对应判据：2.2 三依据加 4.3 节奏三条。

误区三：贫血改造一刀切。症状：推广令要求"三个月内全部 Service 改为充血模型"。根因：把 1.4 的结论读成了风格洁癖——薄规则的查询侧用事务脚本完全正当。纠正：按 1.3 评估表分区治理，核心域充血、查询侧大方保持薄。对应判据：1.4 实验结论第三条。

误区四：事件风暴开成需求评审会。症状：墙上贴的是"系统应该支持××功能"，业务方逐条确认排期。根因：参会名单错了（开发多于业务）、主持人没把时态钉死在"已发生"。纠正：5.1 的名单三原则加过去时铁律；跑偏即拉回，拉不回就休会。对应判据：5.1 刹车三时机。

误区五：评估只做一次。症状：立项时的评估表用了一年，域的位置早漂移了没人知道。根因：把适用性评估当成准入考试而不是持续校准。纠正：每季度半小时重测绘（2.3 四步法的复查节奏），升格降格都要敢动。对应判据：2.3 漂移三信号。

设计误区：动手时错

误区六：聚合画成表关系图。症状：每张表一个聚合根，表外键变聚合引用，开头的"超级模型"就是标准病例。根因：用存储结构替代业务判断——表结构是存出来的，不是设计出来的。纠正：拿 3.5 四判据逐个重审，先问不变量归属，再看事务范围、并发、级联。对应判据：3.5 全部四条。

误区七：值对象该用不用。症状：满屏实体加 id，连金额、地址、日期区间都建表设主键；判等、同步、去重的代码到处长。根因：拿数据库习惯做建模——"要存就得是实体"。纠正：按 3.1 判定流程过一遍高频概念，描述性的收进值对象；存储用嵌入映射解决。对应判据：3.1 两问判定。

误区八：领域事件当队列消息用。症状：事件命名是"请发货""取消订单"，订阅方收到后"执行失败"不知道该不该重试。根因：把事实与命令混为一谈——事件是已发生、不可辩驳，命令是请求、可被拒绝。纠正：词汇表里分开两类词条，命令走命令通道给明确受理方，事件走广播谁爱订阅谁订阅。对应判据：3.3 过去时铁律。

维护误区：做着做着错

误区九：通用语言退化为翻译文档。症状：词汇表还在维护，但代码里的类名是 OrderInfoManager、DataProcessor，词汇表成了给新人看的业务词典。根因：语言与代码失去锚定——2.1 第二条机制被忘掉，改词不再核对代码。纠正：恢复"这个词在代码里对应什么"的评审固定动作，对不上的词条要么补代码改名，要么删词条。对应判据：2.1 机制三条。

误区十：上下文地图上墙后不再修订。症状：墙上那张图是十八个月前画的，新上下文、新边界、新条约都不在上面，新人按图索骥必然迷路。根因：把地图当一次性交付物而不是活文档。纠正：地图与 7.1 的季度复审绑定——每季复审子域漂移时同步修订地图与协作条约，修订记录留痕。对应判据：2.4 契约文档随代码演进。

体检怎么用

三步。第一步对号：拿十误区逐条问"我们有没有这个症状"，命中的记下来——多数项目首检命中三到五条，别慌，命中说明尺子还能用。第二步溯源：每个命中项回读它标注的判据原文，确认是判据没立、还是立了没执行——前者补判据，后者补节奏。第三步入轨：把命中项的纠正动作写进下一迭代的团队计划，并纳入 7.1 的季度复审清单——误区清单只有挂上复审节奏，才不会变成又一份挂在墙上的地图。

三个高频追问

问：清单会上没命中的项目，是不是就安全了？ 答：没有命中只说明"当前没有症状"，不说明判据在执行。体检表查的是病症，判据才查病因——半年不体检不等于健康，同样，体检通过不等于可以停掉季度复审的节奏。

问：命中多条时先治哪条？ 答：按"影响判据还是影响节奏"分流。认知与设计类（一至八）优先——它们在制造新的错误资产，每拖一天都在欠债；维护类（九、十）虽然温和，但它们销毁的是已有资产的正确性，第二优先。同组之内，谁的下游调用方多先治谁。

问：有没有第十一、十二个误区？ 答：一定有，而且每个组织都该攒自己的一份。这份清单的维护方式比清单本身重要：每次事故复盘，归因若能对应一条新误区（症状、根因、纠正），就按 7.1 模式期的蒸馏流程补进来——误区清单是活的判据库，抄来的版本永远缺你们自己的那几条。

全册收口

• 误区与团队水平无关，只与流程里有没有判据有关——热情最高的那条线，往往错得最有创意。
• 认知错在动机（目标写不出业务度量）、设计错在判据（四判据与两问判定）、维护错在节奏（语言锚定与地图复审）。
• 体检三步：对号、溯源、入轨；清单必须挂上季度复审，否则它自己就是第十一个误区。
• 全册判据到此收拢：边界谈判的每一回合都有尺子可用——词有定义域、界有依据、规则有归属、变更有补偿、推广有节奏。

到这里，这场从"满减与优惠券能不能叠加"开始的边界谈判全部讲完。回到你自己的会议室，第一个议题已经现成：你们系统里那个每次改需求都吵的词——它的定义域，谈好了吗？