Appearance
复杂度治理
定位：金融级稳定性方法论（6/6）。系统不会一夜变复杂。它是每个"临时方案"、每次"加一层兼容"悄悄长出来的。而复杂度是稳定性的头号敌人——故障定位慢、预案失配、没人敢动老代码，全是复杂度的利息。本篇写：复杂度守恒与转移、认知负荷三类型、领域划分与防腐层。还写：系统拓扑可视化、"每季度砍一个系统"的减法治理。关联：复杂度的源头一半是决策失误（见 技术决策与ADR）。装箱的边界怎么画见 领域驱动设计在互联网业务开发中的实践。
一、复杂度守恒与转移
先把复杂度拆成两类（Brooks《没有银弹》的老框架，仍然好用）：
- 本质复杂度：业务本身的难度——计息规则、额度管控、还款冲抵顺序。砍不掉，只能用好的领域模型承载。
- 偶然复杂度：我们自己造出来的——过度抽象、防御式拷贝代码、没人敢删的开关、三层兜底各兜各的。
复杂度第一定律：不灭，只转移。
把一个账单系统拆成 30 个微服务：
每个服务的代码确实简单了
│
▼
复杂度去哪了？──► 服务间调用拓扑、分布式数据一致性、跨服务排障链路
本质复杂度没变（计息规则还是那些），
只是额外多了一层"三十个团队之间的协调复杂度"（偶然复杂度）治理目标由此而来：不是消灭复杂度（不可能），是让复杂度待在最便宜的地方。优先转移到平台/框架/中间件（一次实现、处处复用、有专职团队养）。最差的位置是散落在各业务代码里（每个团队都要自己扛一遍）。
反例：每个业务系统自己实现"金额精度处理 + 舍入规则 + 幂等重试"——本质复杂度被复制了 N 份，某一年审计发现三套舍入规则口径不一致，成了资损级问题。正确做法是沉到公共库/平台层，业务侧一行注解。
二、认知负荷三类型
| 类型 | 来源 | 信贷场景例子 | 治理动作 |
|---|---|---|---|
| 内在负荷 | 领域本身的难度 | 计息规则、还款冲抵、征信准入 | 消不掉：积累领域模型、术语表、规则文档 |
| 外在负荷 | 信息呈现方式造成的 | 系统无文档、命名混乱、表结构无注释、架构图过期 | 收益最大：文档、命名规范、拓扑可视化 |
| 偶然负荷 | 实现方式引入的 | 过度抽象的七层接口、防御式拷贝、三版共存的开关 | 严格可控：重构、合并、删除 |
三个务实推论：
- 治理优先级：外在 > 偶然 > 内在。外在负荷是"纯赚"的——系统一行不改，理解成本先降一半；内在负荷硬啃，投入产出最差。
- 团队认知负荷有上限：一个团队同时"主动维护"的系统不超过 2~3 个。超了必然退化为只救火不演进。给团队加系统之前，先算减法（见第五节）。
- 新人上手一个系统的时间是认知负荷最好的度量。上手要 3 个月的系统，和上手要 3 天的系统，稳定性天花板不一样。方法对照 如何快速熟悉一个新的系统。
复杂度没法直接度量，用四个代理指标盯着（进季度治理会，见第六节）：
| 代理指标 | 采集方式 | 预警信号 |
|---|---|---|
| 新人上手时间 | 从入职到第一次独立发布 | > 4 周且趋势上升 |
| 单需求变更影响面 | 平均一个业务需求改动的系统数 | 跨 > 3 个系统联动发布 |
| 告警噪声比 | 无需处理的告警占比 | > 50% 时 oncall 会训练性忽略告警 |
| 发布频率衰减 | 同系统季度发布次数 | 越来越不敢发 = 没人懂了 |
三、领域划分与防腐层
- 限界上下文画错，外在负荷无限上涨：领域按业务边界装箱（放款域、账单域、额度域、催收域）。装箱错了的信号很一致——"每次改一个小需求要跨五个系统联动发布"。这是重新划分边界的最强证据，比任何架构评审都诚实。
- 防腐层（ACL）是把外部复杂度挡在门外的翻译层：
征信渠道A ─┐ ┌─► 额度域自己的模型
征信渠道B ─┼─► 防腐层(翻译/适配) ──┤
合作方C ─┘ （模型转换、字段 └─► 后续演进只改防腐层
映射、语义对齐）
反例：渠道A 的返回结构直接存库、透传到接口和前端——
渠道改一个字段名，库表/接口/前端/报表全链路跟着改，
外部系统的复杂度被原样搬进了自己的房子- 防腐层的成本意识：每层防腐都有维护成本。对外依赖多、变化快的边界（渠道、合作方）最值得做。内部稳定且同构的服务之间硬加防腐层，是在用偶然复杂度对抗想象中的复杂度。加不加，回看该依赖的历史变更频率。
四、系统拓扑可视化
依赖图（示意）：
┌──────────► 额度中心
账单 ──► 放款核心 ──────► 风控决策 ──► 征信渠道(挡板)
│ │
▼ ▼
还款调度 消息中心 ──► 短信/推送平台
│
└──► 逾期标记 ──► 催收系统- 循环依赖检测做成构建期卡口（依赖矩阵/ArchUnit 类工具）：A 依赖 B、B 又依赖 A 的那一刻就显示错误。不是三年后拓扑图变成毛线球才发现。信贷系统的依赖铁律：资金核心域不依赖边缘域（放款核心不能依赖营销/报表）。这条规则写进 CI，违反即失败。
- 核心链路依赖收敛原则：放款同步链路的依赖数设硬上限（如 ≤ 5）。新增一个同步依赖要走评审。对照 技术决策与ADR：每次"顺手多调一个接口"都在给未来的故障半径加一环。
- 反例：依赖图三年没人看，新人接手靠老员工口口相传，口口相传的内容又随着人员流动漏掉一半——外在认知负荷无人治理地上涨，直到某次故障定位在"没人知道还有这条调用链"上浪费一小时。
- 治理动作清单：拓扑图从代码/配置自动生成（手工画的图必过期）。每季度评审一次核心链路依赖数变化。新增系统必须在图上登记才能拿到资源。
拓扑治理的三条硬红线（进 CI 与季度评审）：
- 资金核心域零依赖边缘域（营销/报表/运营后台）——违反即构建失败，不是提示；
- 核心同步链路依赖数 ≤ 5——新增一个依赖走 ADR（见 技术决策与ADR）；
- 依赖图自动生成、季度过堂——手工维护的图必然过期。过期的图比没有图更危险（误导决策）。
五、"每季度砍一个系统"的减法治理
系统数只增不减是组织的默认熵增：临时系统转正、老系统没人敢下线、报表系统一个需求建一个。只考核"建"不考核"砍"，五年后就是 200 个系统里 30 个僵尸。每个僵尸都要值班、都要升级中间件、都是故障候选和攻防演练的死角。复杂度是复利负债。
减法的三种动作：
合并：功能并进主系统，下线独立部署（例：三个报表系统合成一个）
下线：流量归零 + 数据归档 + 机器回收（例：迁移后的老借款系统）
代管：低频系统降级为平台托管/冻结态，只保安全合规更新砍系统 checklist（全部勾选才能执行）：
□ 90 天流量为零（含定时任务、MQ 消费、回调与旁路对账）
□ 依赖方全部迁移完毕（含下游订阅方的书面确认，防"暗依赖"）
□ 数据归档完成且做过一次恢复演练
□ 入口（域名/接口）404 兜底与调用方告知
□ 观察期 30 天后再回收机器资源- "暗依赖"是下线翻车的头号原因。某个季度才跑一次的批处理、某个合作方半年来一次的对账回调，不在监控的常规视野里。所以 checklist 第一条要显式覆盖定时任务与回调，观察期禁止省略。
- 组织机制：把"砍掉/合并一个系统"写进季度 OKR，与新增系统同等权重。架构治理会每次先过减法清单再谈新增。反例：治理会上人人汇报新建了什么，没人汇报下线了什么。五年后新人的第一个问题永远是"这个系统是干嘛的"，没有人答得上来。
六、治理会怎么开：先减法，后加法
季度架构治理会（固定议程 90 分钟）
1. 上季度减法清单验收：下线/合并/代管完成了几个 ── 20 分钟
2. 代理指标过堂：上手时间/变更影响面/告警噪声/发布频率 ── 20 分钟
3. 拓扑红线巡检：循环依赖、核心依赖超限的新增项 ── 15 分钟
4. 本季度减法目标认领：每个域至少认领一个候选 ── 20 分钟
5. 最后才轮到新增系统的立项 ── 15 分钟顺序就是态度：减法不清账，加法不受理。 配套机制：新增系统的立项书必须回答"三年后它归谁养、替代或合并了什么"。回答不了的立项，本质是往负债表上加一笔无主债务。
追问链
怎么向业务方证明"复杂度治理"值得投入？
翻译成他们听得懂的语言：不改代码、只补文档和拓扑图（外在负荷治理）。这可以让新人上手时间从 3 个月降到 3 周。下线一个僵尸系统少一个值班告警源、少一批安全扫描项。复杂度账本挂在故障复盘里最有说服力。"这次定位花了 90 分钟，其中 70 分钟花在理清调用链"就是最好的立项材料。
微服务拆还是合？
用复杂度转移定律算账。拆，是把复杂度从代码移到运维与协调（要求团队有平台能力承接）。合，是把复杂度收回代码（要求领域模型清晰）。判断依据是团队的运维成熟度与业务边界清晰度，而不是"别的公司都拆了"。拆错了可以合回来——但要趁早。服务边界固化在数据里之后，合并就从重构升级成单向门决策了（见 技术决策与ADR）。
砍系统动的是"别人的孩子"，推不动怎么办？
三个杠杆。其一，把僵尸系统的真实持有成本摆上桌——值班人力、安全扫描整改、演练覆盖成本。钱的语言比架构的语言有说服力。其二，砍系统不砍功劳。下线一个系统的复盘展示与立项一个系统同等权重（组织奖励什么就得到什么）。其三，用数据不靠权力——流量为零 90 天的证据 + 暗依赖排查清单，让"再观察观察"没有立足点。
一句话总结
复杂度守恒，治理的本质是转移定价。把本质复杂度沉到平台与领域模型。把外在负荷用文档和拓扑可视化清零。把偶然负荷用重构和减法删除。每个季度，既要能回答"加了什么"，也要能回答"砍了什么"。
2026-10 新增（金融级稳定性方法论系列）。