上下文映射九种模式：从团队权力关系理解限界上下文协作

1. 九种模式先别急着背它们描述的是团队之间的权力关系第一次接触“上下文映射”这个概念时我以为它是一张服务依赖图——谁调谁、走 HTTP 还是消息队列、超时设多少。后来在一个跨团队的对账项目里栽了跟头才反应过来那九种模式讲的压根不是技术是团队之间谁求谁、谁能改接口、谁只能被动适配的关系。当时两个团队各自维护一套“结算单”概念字段名一样、语义不同联调时对着日志吵了三天最后发现问题的根子在组织边界不在代码。这就是上下文映射要解决的事在领域驱动设计里限界上下文划定了模型的边界而上下文映射描述的是这些边界之间如何协作、由谁主导、用什么方式交换信息。它是一张组织与模型的联合地图不是部署架构图。九种模式——合作关系、共享内核、客户-供应商、顺从者、防腐层、开放主机服务、发布语言、分离方式、大泥球——本质上是对“两个上下文之间关系形态”的归纳每一种都对应着特定的权力结构、沟通成本和演化路径。我见过太多团队把这张图画得很漂亮箭头、颜色、图例一应俱全然后贴在墙上再也没人看。问题出在他们画的是“系统长什么样”而不是“人和模型怎么相处”。前者是静态的后者是会变的。一个下游团队今年没话语权明年业务做大了就可能翻盘映射关系也得跟着变。所以聊这九种模式之前得先把映射图到底在表达什么说清楚。1.1 限界上下文是语言边界不是部署边界很多人把限界上下文直接等同于微服务一个服务一个上下文拆得整整齐齐。这个理解偏差会带来一连串问题。限界上下文的本质是同一个词在不同边界内含义不同边界内保持语言一致。它可以是某个服务也可以是单体里的一个模块、一个子系统甚至是一段独立的命名空间。判断依据是语言不是进程。拿“优惠券”举例。营销上下文里优惠券是投放资源关心的是发放量、核销率、触达人群结算上下文里它是抵扣凭证关心的是面额、适用范围、叠加规则财务上下文里它是成本项关心的是计提、摊销、对账口径。这三个“优惠券”如果强行统一成一个实体类结果一定是一个四十多个字段、一半字段在特定场景下为 null 的怪物外加一堆互斥的状态机分支。承认它们不是同一个东西各自建模边界内语言自洽这才是限界上下文要干的事。代码上体现为独立的包、独立的领域模型、独立的术语表。术语表这件事特别容易被忽略但它是最便宜的边界标记——一个上下文里“订单”指什么写清楚新人和外部团队就不会乱用。1.2 映射图上的箭头标的是上下游不是调用方向这是第二个高频误解。调用方向是技术事实上游下游是权力事实。A 服务调用 B 服务不代表 A 是下游。真正的判断标准是谁有能力单方面改变接口而不顾对方死活谁就是上游谁必须跟着对方变谁就是下游。画映射图的时候我习惯在每个上下文旁边标注三样东西角色上游 U / 下游 D、关系类型、沟通机制。沟通机制这一项最容易被漏掉但它恰恰是映射图能不能落地的关键。两个团队是每周同步一次还是季度对齐还是只靠文档直接决定了这段关系能承受多大的变更频率。还有一个细节映射图里应该标出哪一段关系是稳定的哪一段是临时的。临时关系比如某个活动期间两个上下文要临时对接活动结束就拆。如果不标后人会把它当成永久架构来维护越积越重。1.3 九种模式其实只有三类加两个特例把九种模式按权力结构归类记起来会轻松很多类别模式核心特征平级协作合作关系、共享内核双方对等共同承担变更上下游客户-供应商、顺从者、防腐层有明确的上游下游下游决定姿态对外服务开放主机服务、发布语言上游主动面向多个下游提供稳定契约特例分离方式、大泥球前者主动不集成后者是被动形成的混沌状态这个分类不是学术上的严格划分是我自己在项目里用来快速定位的。看到一个集成关系先问“双方对等吗”对等就看平级协作不对等就看下游想采取什么姿态如果上游要服务一堆下游就看对外服务那一栏。分类清楚了选型就有了起点。需要说明的是这九种模式来自领域驱动设计的经典归纳具体到每个项目怎么用、用哪几种跟团队规模、组织结构、历史包袱关系极大。下面我按这个分类逐个拆重点讲每种模式在真实项目里的适用条件和我踩过的坑。2. 合作关系与共享内核两个平级团队绑在一起的两条路平级协作是九种模式里看起来最理想、实际最难维持的一类。两个团队地位对等没有谁必须听谁的听起来很美好但没有明确的权力约束冲突就只能靠沟通解决。沟通这东西顺的时候什么都好说一旦排期紧张、目标不一致最先崩的就是它。所以这两种模式都有明确的适用边界用错了比上下游关系还难受。2.1 合作关系两个团队绑在一条船上合作关系的定义是两个上下文有大量交叉任何一方的失败都会拖累另一方因此双方共同承担变更责任接口改动要一起商量、一起发布。它的前提是目标一致且依赖对称。注意“对称”这两个字如果只是 A 依赖 B、B 不怎么依赖 A那本质上还是上下游硬套合作关系会让 B 觉得被绑架。我在一个供应链项目里用过合作关系。采购上下文和库存上下文几乎是同一批业务动作的两面采购下单后库存要预占库存不足采购要改单。两边团队各五个人坐同一个办公区每周一早上对一次本周的接口变更。这个模式跑了大概八个月效果不错因为双方确实是互相依赖谁也离不开谁。落地时我总结了几条硬性要求。第一接口契约放在双方都能改的共享仓库里不能放在某一方的代码库里让对方提 PR。第二变更必须双向通知并且有明确的冻结窗口比如大促前两周不允许改契约。第三有一个双方都认的裁决人出现分歧时能拍板否则会陷入无休止的讨论。第三条最容易被忽略我见过两个团队因为一个字段该不该加吵了两周最后是双方主管一起开会才解决的。合作关系的失败模式很典型一开始大家热情很高同步会开得勤三个月后各自忙起来同步会改成两周一次半年后改成“有事再说”然后某天一方悄悄改了个字段另一方线上炸了。这不是人的问题是模式缺少强制约束。所以用合作关系时我会额外加一层自动化契约测试放在 CI 里任何一方改契约但没更新测试流水线直接红。2.2 共享内核共用一块地谁都不能随便动共享内核是两个上下文共同拥有一小块模型和代码。经典定义里强调这块要足够小、足够稳定、双方都认可。它解决的是“有些概念在两个上下文里确实完全一样重复建模反而增加不一致风险”的问题。典型的共享内核内容金额与货币类型、数量与单位、统一的业务标识符类型、领域事件的基类结构、时间区间表示。这些东西的特点是语义在所有上下文里完全一致变更频率极低而且一旦不一致会引发跨上下文的计算错误。我见过做得好的共享内核是一个独立的代码仓库独立版本号两边在构建配置里锁定同一个版本。任何改动走单独的评审流程双方各出一名评审人合并后发版两边一起升级。这个流程听起来重但因为变更频率低一年也就十几次完全可控。做得差的共享内核我见得更多。最常见的结局是它变成了公共代码仓库一开始只有金额和 ID后来有人觉得日期工具挺通用塞进去再后来有人把日志封装、HTTP 客户端、重试策略也塞进去两年后这个仓库有两百多个类谁都不敢动谁都在用任何一次升级都是一场冒险。这不是共享内核这是把耦合伪装成了复用。判断一块代码该不该进共享内核我用三个问题过滤两个上下文是不是都真的在用语义是不是完全一致变更频率是不是足够低三个问题有一个答不上来就不该进。还有一个隐性标准这块代码如果改坏了两个上下文是不是都会出问题如果只有一个会出问题那说明它本来就不该共享。2.3 这两种模式的适用条件与真实代价把两种模式放一起对比判断会清晰很多维度合作关系共享内核耦合程度高流程层面强耦合中代码层面弱耦合沟通成本很高需要持续同步较低按变更触发适用团队规模两个小团队最好同地办公任意规模但要有明确 owner主要风险同步机制松弛后失控边界失守变成垃圾场适合的场景业务上强相关、互相依赖基础概念一致、变更极少我个人的经验是小团队之间用合作关系的成功率高跨地域、跨层级的大组织里用共享内核更现实。原因很简单合作关系依赖高频沟通异地跨时区基本没戏共享内核依赖的是流程约束只要能守住“小”和“稳”这两条地理距离影响不大。还有一个容易被忽略的点这两种模式都会让两个上下文产生发布节奏上的耦合。合作关系中一方要发版另一方得配合验证共享内核升级两边都得跟着升。如果两个上下文的发布频率差异很大比如一个是每周发一个是每季度发这种耦合会很痛苦。选型时要把发布节奏作为硬指标看不能只看模型层面合不合适。3. 客户-供应商、顺从者、防腐层下游团队的三种活法上下游关系是现实中最常见的一类。有上下游就有权力不对等下游团队面对上游的模型和接口通常只有三种姿态争取话语权、放弃自主权、建墙隔离。这三种姿态分别对应客户-供应商、顺从者、防腐层。选哪一种取决于下游的议价能力、上游模型的质量、以及这个上下文对业务的重要性。选错的代价不小我见过核心域用了顺从者结果被上游拖着走的也见过支撑域硬建防腐层结果维护成本压垮团队的。3.1 客户-供应商下游有需求上游有义务响应客户-供应商模式的核心是下游能提需求上游有责任排期并给出承诺。双方不是平等的但下游有正式的诉求通道和一定的议价能力上游不能完全无视。这个模式成立需要两个条件。第一下游的业务价值足够大上游有动力配合第二组织上有机制保障比如双方有共同的上级或者有正式的服务级别约定。缺了第二条所谓“客户-供应商”很快就会退化成下游单方面求人。落地时我建议做三件事。建立需求池下游把集成相关的需求统一提报不要走私下沟通约定变更通知窗口上游改接口前至少提前一个迭代通知破坏性变更要提前两个迭代定期对齐会频率不用高双周一次或每月一次重点是对齐即将到来的变更不是汇报进度。我经历过一次比较成功的客户-供应商关系。订单上下文是下游支付上下文是上游订单团队每个季度把集成需求整理成清单和支付团队一起过一遍双方确认排期。支付团队要改回调协议时提前一个月通知订单团队有充足时间适配。这套机制跑了两年没出过大问题。失败的情况也见过。下游团队觉得自己是“客户”提需求理直气壮但上游团队压根没有服务意识需求提了半年没人理。这种情况下模式名义上成立实际上已经退化下游要么往上找组织力量介入要么就老老实实改用防腐层自保。3.2 顺从者主动放弃模型自主权换取集成成本最低顺从者的意思是下游直接采用上游的模型不做任何翻译和隔离。上游怎么定义下游就怎么用。代价很明确——下游的领域模型被上游污染上游的变更会直接传导进来。收益同样明确——集成成本最低没有翻译层要维护。很多团队对这个模式有心理抵触觉得用顺从者就是“不专业”。我的看法恰恰相反在支撑域和通用域用顺从者是非常理性的选择。一个内部报表上下文上游是订单中心报表本来就是围绕订单数据做统计非要建一层防腐层把订单模型翻译成“报表自己的订单模型”翻译完发现字段一一对应这层翻译除了增加维护成本没有任何价值。用顺从者有几个前提得说清楚。上游模型质量要过关如果上游模型本身设计混乱、命名随意、语义模糊下游跟着用就是灾难。上游变更不能太频繁频繁变更会持续冲击下游。下游不能是核心域核心域被外部模型绑死长期看一定会限制业务演化。还有一个实操建议用顺从者时要把这个决策显式记录下来。写进架构决策记录写清楚“我们接受上游模型原因是集成成本高于模型污染成本如果未来上游变更频率上升或本上下文升级为核心域需要重新评估”。这句话看着像形式主义但真到了要重构的时候它能帮你省掉大量扯皮——后人知道当初为什么这么选也知道什么条件下该改。3.3 防腐层下游自己建一道墙隔离上游的模型防腐层的做法是下游在自己的边界内建一层翻译层上游的模型进来先经过转换变成下游自己的领域模型。好处是下游的模型完全自主上游怎么变都影响不到内部代价是多一层维护成本调试链路变长而且这层翻译本身也会腐化。防腐层适合的场景很明确下游是核心域上游模型质量差或者变更频繁两边模型语义差异大。三个条件里满足两个就值得建。具体怎么建我给一个我自己常用的分层结构acl/ adapter/ 协议适配HTTP/消息/文件各种来源统一成内部输入 translator/ 模型映射上游 DTO 转下游领域对象 facade/ 对外暴露的防腐层入口内部只依赖这一层 error/ 异常映射上游错误码转内部异常体系几个关键细节。异常映射必须做上游返回的业务错误码要翻译成下游能理解的异常类型否则下游代码里会出现大量if (upstreamCode xxx)的判断。未知字段要容忍上游加字段不能导致下游反序列化失败JSON 解析要配忽略未知字段。超时和重试策略要在防腐层统一收口不能让上游的不稳定直接传导到业务代码里。防腐层最大的坑是越写越厚。一开始只是字段映射后来发现上游有些业务规则挺好用复制进来再后来上游有个计算逻辑也复制进来最后防腐层里躺着上游业务的半份实现上游一改这边还得跟着改隔离的意义完全丧失。我的做法是给防腐层定一条硬规矩只做翻译不做业务判断。任何带 if-else 业务分支的逻辑一律不准放在防腐层里要放到领域层去。3.4 三种姿态怎么选一张判断表每次有人问我该用哪种我都会让对方先回答四个问题然后对着表看判断项客户-供应商顺从者防腐层下游是否有议价能力必须有不需要不需要上游模型质量中等以上必须高不限上游变更频率中低低高也可以下游是否核心域可以是最好不是建议是维护成本中最低最高补充一点个人经验同一个下游上下文对不同上游可以用不同姿态。这不是摇摆是务实。比如订单上下文对支付上下文用客户-供应商支付团队配合度高对物流上下文用防腐层物流接口老变、模型也乱对内部风控用顺从者风控模型标准、变更少。一个上下文对外有几条边每条边单独判断这才符合实际。4. 开放主机服务与发布语言上游团队怎么把接口做成产品前面讲的三种姿态都是站在下游视角。换成上游视角如果有一堆下游要对接一个个定制接口会被拖死这时候就需要开放主机服务和发布语言。这两个模式经常成对出现核心思路是上游把集成能力产品化用一套稳定的、有版本的、文档化的契约服务多个下游。4.1 开放主机服务一套接口服务所有下游开放主机服务的关键在于“开放”和“主机”两个词。开放是指接口对所有下游公开不针对单个下游定制主机是指上游承担起服务提供者的责任包括稳定性、版本管理、文档、支持。这个模式成立的前提是上游有服务多个下游的意愿和组织授权。很多团队技术上做得到组织上做不到——上游团队有自己的 KPI没有动力为下游的便利投入。这种情况下硬推开放主机服务最后会变成接口文档写了一堆实际维护跟不上下游怨声载道。落地时的几个要点。接口设计要面向通用场景不能为某个下游开小灶。一旦为某个下游加了特殊字段其他下游很快就会要求同等待遇接口会迅速膨胀。版本管理要提前规划我习惯用 URL 版本号或者消息里的版本字段破坏性变更发新版本旧版本保留至少两个发布周期。废弃策略要写清楚哪个版本什么时候下线提前多久通知这些都要形成文档。接口形式上REST 和消息队列都行取决于下游的消费模式。同步查询多的用 REST事件通知多的用消息。我倾向于关键业务事件用消息查询用 REST两者配合。4.2 发布语言上下游共享的一套交换格式开放主机服务需要一种语言来描述交换的数据这就是发布语言。它通常表现为 schema、IDL、或者一套约定俗成的 JSON 结构。发布语言的要求是稳定、文档化、有版本、能表达业务语义。我在项目里用过 JSON Schema 和 Protobuf 两种。JSON Schema 的好处是可读性强前后端都能看懂坏处是校验能力弱复杂约束表达不了。Protobuf 的好处是强类型、有代码生成、向前向后兼容做得好坏处是对非技术方不友好改一次要重新生成代码。不管用哪种有几条约定必须写进发布语言的规范里。枚举值必须容忍未知项下游遇到不认识的枚举值不能崩要有默认处理。单位要明确金额是分还是元重量是克还是千克时间戳是秒还是毫秒这些不写清楚早晚出事故。可选字段和必填字段要标清楚下游不能假设可选字段一定存在。扩展字段的命名规则要统一比如统一用ext_前缀避免和未来正式字段冲突。这些约定看起来琐碎但每一条背后都有真实事故。我印象最深的一次是金额单位没约定清楚上游按分传下游按元解析一笔订单金额放大了 100 倍对账时才发现。从那以后我在任何发布语言里都会把单位写成字段名的一部分比如amount_in_cents丑是丑了点但不会再错。4.3 两个模式组合使用才有效开放主机服务单独用容易出现“接口开了但没人维护”的情况发布语言单独用只是一份格式文档没有服务承诺。两者组合才是完整的“平台化”能力上游用开放主机服务承诺稳定性和支持用发布语言承诺数据格式的兼容性。组合使用的判断标准也简单如果上游要服务的下游超过三个且这些下游的集成需求有共性就值得投入做 OHS PL。如果只有一两个下游定制接口的成本反而更低不必强上。还有一个现实问题开放主机服务需要上游有专门的投入。接口文档、示例、沙箱环境、变更通知、技术支持这些都要人。我见过一些团队把 OHS 当成“把接口公开出去就完事”结果下游对接成本极高最后大家还是走私聊、走定制。所以推这个模式之前先确认上游团队有没有对应的资源和考核没有的话先做客户-供应商更实际。5. 分离方式与大泥球一个主动放弃一个被动形成最后这两个模式经常被放在一起讲但它们性质完全不同。分离方式是主动决策——两个上下文评估后决定不集成大泥球是被动结果——多个上下文混在一起边界消失。前者是理性选择后者是需要面对的现实。把这两个放一起是因为它们都涉及“边界不存在或不该存在”的情况。5.1 分离方式不集成也是一种设计分离方式的意思是两个上下文之间不做任何集成各自解决各自的问题哪怕功能上有重叠。这个模式在很多团队里不受欢迎因为大家有一种“必须打通”的执念觉得重复建设就是浪费。但算一笔账就清楚了。集成的成本包括接口开发、联调、上线后的维护、变更时的同步、出问题时的排查。两个上下文如果业务重叠只有 20%为了这 20% 建一套集成长期的维护成本很可能远超重复建设的成本。尤其是当两个上下文的业务节奏差异很大时集成会把两边绑死。我做过一次分离决策。两个业务线都需要一套简单的审批流功能重叠大概三成但两边的审批规则、组织架构、流转逻辑差异很大。一开始想做一个统一的审批中台评估下来发现要做大量配置化而且两边都不愿意为对方的需求妥协。最后决定各做各的各自用一个轻量实现。两年下来两套审批流各自演进维护成本都不高比强行统一省事得多。用分离方式的关键是把决策显式化。写下“我们决定不集成原因是重叠部分价值低于集成维护成本如果未来重叠度上升或出现数据一致性要求重新评估”。不写清楚后人会以为是漏做了又去补一套集成。5.2 大泥球不是模式是需要被看见的现状大泥球在九种模式里的位置比较特殊它不是一个应该被选择的模式而是一种需要被识别和面对的状态。典型特征是多个上下文共享同一套数据库表多个团队直接读写同一批数据模型边界模糊任何改动都可能引发连锁反应。识别大泥球有几个信号。同一个实体在多个地方有不同的字段子集比如用户表被五个团队各读写一部分字段。改一个字段要协调三个以上团队。没有明确的模型 owner。依赖关系图是一团乱麻找不到清晰的分层。面对大泥球我的态度是先别急着重构先把它画出来。用依赖分析工具扫一遍代码和数据库访问画出现状图标注出哪些部分是高频变更区哪些是事故高发区。这张图的作用不是好看是让所有人对现状有共识。很多时候问题的根源不是技术是没人愿意承认自己正站在泥球上。5.3 面对大泥球的处理顺序处理大泥球我不建议一上来就搞大重构。顺序应该是这样第一步冻结扩张。新功能不要再往泥球里加新上下文独立建通过防腐层和泥球交互。这一步止住恶化趋势成本最低收益最直接。第二步隔离高频变更区。找出变更最频繁、事故最多的那块优先把它抽出来做成独立上下文。判断标准是变更频率乘以影响面不是代码量。第三步逐步建防腐层。对暂时抽不出来的部分在调用方建防腐层把泥球的模型挡在外面。这一步能显著降低新代码被污染的速度。第四步绞杀。新逻辑走新上下文旧逻辑逐步下线直到泥球缩小到可以整体替换。这个顺序的核心逻辑是先止血再治病。我见过反过来的做法一上来就要重写整个系统结果业务等不及新系统还没上线旧系统又堆了一堆需求最后两边都烂尾。6. 我在真实项目里用过的组合以及选型时看的四个维度单独讲九种模式容易让人觉得要二选一实际项目里几乎都是组合使用。一个中等规模的系统对外可能有七八条边界每条边界的模式都不一样。关键不是记住九种模式的定义而是有一套稳定的判断方法能在具体场景下快速定位该用哪种。6.1 四个判断维度我判断用哪种模式主要看四个维度第一权力关系。双方谁更能单方面改接口对等就看平级协作不对等就看下游姿态。这一条决定了可选范围。第二上下文的重要性。是核心域、支撑域还是通用域核心域必须保护模型自主性支撑域可以务实一点通用域能买就买、能用就用。第三变更频率。上游接口一年改一次和一个月改一次应对方式完全不同。高频变更要么建防腐层要么推动上游做开放主机服务加版本管理。第四团队能力与资源。防腐层、开放主机服务都需要投入团队人手不够时顺从者反而是理性选择。选一个维护不起的模式比选一个“不够优雅”的模式危害大得多。这四个维度里我认为权力关系是最硬的约束。技术方案可以调整组织权力结构短期内改不了。很多方案失败不是因为设计不好是因为假设了一个不存在的权力关系。6.2 一张选型参考表把四个维度和九种模式对应起来我做了一张自己常用的参考表场景特征推荐模式备选要避免双方强相关、目标一致、能高频沟通合作关系共享内核单方面定制接口有一小块完全一致的稳定概念共享内核各自建模把共享内核做成公共库下游有议价能力、上游愿意配合客户-供应商防腐层名义合作、实际求人下游是支撑域、上游模型质量高顺从者防腐层硬建防腐层增加成本下游是核心域、上游模型差或变更频繁防腐层客户-供应商顺从导致模型污染上游要服务三个以上下游开放主机服务 发布语言逐个定制只开接口不维护业务重叠低、集成成本高于收益分离方式轻量集成为集成而集成多团队共享数据表、边界模糊先画现状图 冻结扩张逐步隔离直接大重构这张表不是标准答案是起点。具体项目里还要看历史包袱、人员流动、上线节奏这些软因素。6.3 一个系统里混用多种模式的真实例子拿一个零售平台举例。订单上下文是核心它对外有几条边对支付上下文用客户-供应商。支付团队配合度高双方有定期的接口对齐订单团队提的适配需求能在两个迭代内排期。对物流上下文用防腐层。物流侧的接口是外部系统对接来的字段命名混乱、变更没有预告订单侧建了一层翻译把物流的运单模型转成自己的履约模型。对内部报表用开放主机服务 发布语言。订单上下文把订单事件以统一的 schema 发出去报表、风控、客服几个下游都订阅同一套事件。订单团队维护 schema 的版本下游按自己的节奏升级。对促销上下文用合作关系。促销要读订单、订单要感知促销规则两边强相关团队规模都不大坐得也近每周同步一次。对历史遗留的会员系统用分离方式。会员数据和订单只有很弱的关联历史系统改造代价太大评估后决定不集成订单侧需要会员信息时走一次离线同步。这个例子里一个上下文对外用了五种模式。这不是设计混乱是务实。每条边界的权力关系、变更频率、业务重要性都不一样用一种模式套所有边界一定会出问题。7. 映射图落地时最容易走样的几处和我的处理办法画图不难难的是图上的关系能真的运转起来。我参与过的项目里映射图走样的方式高度相似来来回回就那么几种。把它们列出来比讲抽象原则有用。7.1 把映射图画成了组织架构图最常见的走样图上的方块就是部门箭头就是汇报关系画完发现跟组织架构图一模一样。这说明画图的人压根没从模型角度想问题只是把组织关系翻译了一遍。映射图的方块应该是限界上下文一个部门可能对应多个上下文一个上下文也可能横跨两个部门。判断标准是语言边界不是汇报线。我画图时习惯在每个方块下面标注这个上下文的核心术语术语不同才是不同的上下文术语相同就该合并。7.2 共享内核变成了公共代码仓库前面提过这里再强调一次因为太常见了。共享内核的准入标准要写死语义完全一致、双方都在用、变更频率低。三条缺一不可。每次有人想往里加东西就让他回答这三个问题答不上来就放到各自上下文的内部工具里。还有一个操作层面的办法给共享内核设一个体量红线比如代码行数或者类数量超过某个值就冻结新增必须先清理再准入。这个红线是硬约束比讲道理管用。7.3 防腐层写成了复制粘贴层防腐层的职责是翻译不是复制业务逻辑。我见过太多防腐层里塞满了上游的业务规则上游一改这边跟着改隔离完全失效。控制办法有两个。代码评审时专门看防腐层里有没有业务分支任何 if-else 涉及业务判断的一律打回要求移到领域层。给防腐层设复杂度上限比如单个 translator 类的圈复杂度不超过某个值超了就必须拆分或者重新评估设计。这些手段有点土但有效。7.4 映射关系没跟发布流程挂钩映射图上标了“客户-供应商”但两边的发布流程完全没有交集上游想发就发下游被动接招。这种关系名义上成立实际上已经退化成“上游说了算”。解决办法是把映射关系写进发布流程。客户-供应商关系上游的破坏性变更必须走下游的确认合作关系双方发布前要互相通知开放主机服务版本废弃要提前公告。这些不是技术问题是流程问题但如果不落到流程里图上的关系就是空话。7.5 画完就当定稿映射图是会变的。团队重组、业务调整、系统拆分任何一个变化都会让原来的关系失效。把图当成一次性交付物半年后它就和现实脱节了。我现在的做法是把映射图当成活文档每个季度过一遍。过的时候只问三个问题哪些关系变了哪些模式用错了哪些临时的关系该清理了半个小时能过完但能保证图始终反映现实。这个习惯带来的一个额外好处是团队对边界变化的敏感度会提高。以前边界悄悄模糊了没人管现在每季度过一遍问题刚冒头就能被发现。最后分享一个我自己的体会。这九种模式里真正在项目里高频用到的其实就那么四五种防腐层、客户-供应商、开放主机服务、共享内核、分离方式。合作关系用得不多因为对沟通要求太高顺从者很多人用了但不承认大泥球是常态不是选择。与其纠结九种模式背没背全不如把常用的那几种吃透知道什么时候该用、用了之后怎么维护、什么信号出现时该换。我见过把九种模式讲得头头是道、真到项目里一条边界都理不清的人也见过只懂三种模式但每条边界都处理得干干净净的人。后者才是真正会用的人。