回答“系统为什么越来越难改，以及怎样在不停服、不豪赌的前提下把结构性负担一点点收回来”
| 常见表象 | 更可能的债务根因 | 为什么它是架构债 |
|---|---|---|
| 一个需求要改很多模块和很多人 | 边界不清、模块职责交叠、共享依赖太多 | 问题不在某个函数，而在变化无法被限制在局部区域 |
| 服务拆了，但发布和排障更痛苦 | 契约治理弱、观测弱、发布护栏没补齐 | 结构变细了，但系统演进能力没同步提升 |
| 数据库一变，接口、任务、报表全跟着震 | 数据 ownership 混乱、共享表过多、迁移缺乏过渡策略 | 状态层已经把服务边界重新粘回去了 |
| 历史临时方案越堆越多，没人敢大面积清 | 没有偿债节奏、没有债务排序、没有小步改造路径 | 组织知道有问题，但缺少可执行的偿还机制 |
| 每次改结构都像一场高风险迁移 | 交付链不稳、回滚难、缺少兼容发布与验证护栏 | 说明架构演进和交付能力已经脱节 |
| 债务类型 | 典型信号 | 优先偿还原因 | 常见动作 |
|---|---|---|---|
| 边界债 | 一个需求经常跨很多模块、很多 repo、很多 owner | 它直接决定改动是否能被局部化 | 重新划清职责、抽离核心域、限制横切逻辑扩散 |
| 依赖债 | 共享库、工具类、直连下游、隐式调用越来越多 | 它会让系统越改越像一团连线 | 收束依赖方向、增加中介边界、补契约与 anti-corruption 层 |
| 数据债 | 共享数据库、大表万能字段、数据 ownership 不清 | 数据债往往是最硬的粘连层 | 明确主数据归属、拆读写路径、用过渡层和迁移窗口替代硬切 |
| 契约债 | 接口一改就炸下游，事件 schema 靠口头约定 | 它会把所有变更都变成组织级同步动作 | 做兼容演进、schema 校验、版本策略、消费者契约测试 |
| 交付债 | 不敢改结构，因为一发版就像做手术 | 没有安全发布能力，很多债根本没法还 | 灰度、双写双读、回滚点、流水线门禁、结构性验证 |
大多数团队只是模糊知道系统难改，但没有明确把债分成边界债、数据债、契约债、交付债，所以永远只能喊“重构一下”。
一旦偿债被包装成长期冻结业务的大项目，业务方天然会抗拒，最后只能继续堆临时方案。
很多债不是没人想还，而是没有兼容发布、灰度验证、双轨过渡和回滚手段，导致任何结构动作都太危险。
如果只说“代码太烂”“结构不好看”，组织很难买单；如果能说清楚它在拖慢哪个价值流、增加哪些事故概率，偿债才会进入优先级讨论。
更稳的偿债通常是小步收边界、补护栏、切共享、建过渡层，而不是一次性重写。
新系统也会很快产生架构债，尤其是在增长快、需求急、共享逻辑多的时候。
很多团队是把单体里的边界债和数据债直接复制到了网络上，这不叫偿债，叫债务分布式化。
现实里很少有完全稳定的时候。更实际的做法是让偿债成为持续动作，而不是幻想一个未来空窗期。
很多最该优先还的架构债，并不是“最丑”的那块，而是“最拖未来变化速度”的那块。
| 如果你正在处理什么问题 | 建议配套页 | 为什么连着看 |
|---|---|---|
| 想先建立架构判断语言 | 《软件架构基础》 | 先知道架构在权衡什么，再判断哪些负担值得优先偿还 |
| 想建立持续演进和验证机制 | 《演进式架构》 | 它更适合解释偿债为什么必须和适应度函数、治理护栏连在一起 |
| 想从单体或历史后端逐步走向更合适结构 | 《从单体到微服务》 | 架构偿债解决“为什么要还”，迁移书页解决“怎样安全地走” |
| 想把债务放回真实后端系统里看 | 后端工程 | 很多架构债最后都会投影成后端交付、数据正确性和依赖治理问题 |
| 想把结构性债务接回测试和验证体系 | 测试与质量工程 | 很多架构债之所以长期积累，是因为组织没有结构回归信号 |
| 想看团队边界和平台边界怎么影响偿债 | 《团队拓扑》 | 有些债不是代码债，而是 ownership 和认知负担设计出来的债 |
| 想继续深挖 API / 事件 / 数据层面的债 | API / 系统集成、消息事件、数据库 | 架构债常常会继续展开成契约债、事件债和数据库演进债 |