Evolvability

解决什么问题：让架构能应对未知的未来变化，而不是只应对已知的需求——避免"完美实现当前需求但无法扩展"，把可演化性作为架构的核心质量属性（capability > actuality）。

它是什么

可演化性（Evolvability） 是系统架构的核心质量属性——它衡量系统对未来变化的友好程度：

SE@G Ch 1 给出了精确定义： "Your project is sustainable if, for the expected life span of your software, you are capable of reacting to whatever valuable change comes along, for either technical or business reasons." "Importantly, we are looking only for capability—you might choose not to perform a given upgrade, either for lack of value or other priorities."

关键洞察：可演化性 = capability（能变），不是 actuality（实际在变）。能变意味着不必解释每一次变化——系统有应对变化的能力，团队可以选择不变化。

控制论 Ch 18 §18.1 的"不完备信息系统"对应可演化性：完备信息系统 = 当前需求已知 → 不需要演化性；不完备信息系统 = 未来需求未知 → 必须有演化性。

IDDD Ch 3 Bounded Context 的设计直接影响可演化性： BC 边界清晰 = 业务变化时只影响一个 BC；BC 边界模糊 = 业务变化影响全系统。

EDM Ch 17 自然演化是可演化性的应用形态： "event-driven architectures should be guided by the natural evolutionary process of business"——架构的演化 = 业务演化的镜像。

V2 视角（V2.7 B7 段 5）：可演化性是 B7 的核心概念——B7 不是"实际在演化"，是"能演化"。

关键属性

属性	含义	度量
Capability > Actuality	能变 > 实际在变	不变也能演化 = 高演化性
应对未知变化	不是应对已知需求	假设的需求变化次数 / 实际应对次数
架构内嵌	不是流程要求	模块边界清晰度 / 依赖图深度
业务镜像	架构 = 业务的镜像	BC 边界对齐业务边界
可逆性	变化可回滚	每次发布的回滚成本
增量性	可增量变化	大变化的原子化程度
学习性	变化过程能学习	postmortem 闭环率 / ADR 数量
可持续	长期能持续演化	5 年内能跟上的技术换代次数

怎么用

场景 1：度量可演化性

5 个量化指标：

1. 修改成本：加一个 feature 平均要改多少文件 / 多少服务 / 多少团队
   → 越低越好

2. 回滚成本：一次发布后回滚需要的平均时间
   → 越短越好

3. 学习成本：新工程师理解一个模块需要的平均时间
   → 越短越好

4. 依赖深度：模块间依赖图的平均 / 最大深度
   → 越浅越好

5. 技术债比例：重构 / 新功能的时间投入比
   → 持续投入 = 健康；下降 = 技术债堆积

场景 2：提升可演化性的工程实践

架构层：

1. 清晰的 Bounded Context（IDDD Ch 3）
   - BC 边界对齐业务边界
   - BC 之间通过 Context Map 显式协调
   - 每个 BC 可独立演化

2. 标准化接口
   - API 契约稳定（避免 breaking change）
   - 事件 schema 向后兼容（EDM Ch 17 模板）
   - 版本化外部接口

3. 抽象的可扩展性（OCP 原则）
   - 不修改代码就能扩展行为
   - 通过策略模式 / 插件 / 配置

流程层：

1. Deprecation 纪律（SE@G Ch 15）
   - 标记 deprecated → 监控使用 → 给迁移路径 → 删除
   - 不积累"既不能删也不能改"的死代码

2. Large-Scale Changes 模板（SE@G Ch 22）
   - 渐进式重构，原子化 commit
   - 每个 commit 可独立 review / 回滚

3. ADR（架构决策记录）
   - 每次大决策都有"为什么"记录
   - 未来人不需要重新争论已决策的问题

组织层：

1. 团队 = BC（Conway 定律）
   - 每个 BC 有独立团队
   - 团队可以独立决策 BC 内部演化

2. 学习型组织（Learning Org）
   - postmortem 闭环
   - 跨团队知识共享
   - 鼓励实验

场景 3：识别"可演化性失效"

5 个失效标志：

1. "我们不能升级框架"——版本锁定
2. "我们不能改这个接口"——太多调用方
3. "我们不能拆这个服务"——依赖图太深
4. "我们不能换这个数据库"——schema 和代码耦合太紧
5. "我们不能动这段代码"——无人理解

应对：每个失效标志都对应一个重构活动（参 Refactor 文档）。

场景 4：可演化性的反模式

反模式 1：过度设计

症状：为了未来可能的需求做大量抽象
后果：当前需求实现慢 / 代码难理解 / 维护成本高
应对：只在已有多个实例后再抽象（"Rule of Three"）

反模式 2：欠设计

症状：完全不做架构抽象，直接堆代码
后果：业务稍变就要重写
应对：识别核心 BC 边界 + 关键接口契约

反模式 3：演化的可逆性没设计

症状：删表 / 删服务 / 删团队，没考虑回退
后果：决策保守，演化停滞
应对：每个演化决策都问"回退成本"

常见误区

"可演化性 = 灵活 = 抽象" ——错。可演化性 ≠ 过度抽象。正确的可演化性 = 清晰的 BC + 标准化接口 + 可逆的演化
"可演化性 = 实际在演化" ——错（SE@G Ch 1 反对）。可演化性 = capability（能变），actuality（实际在变）不重要
"可演化性 = 可维护性" ——错。可维护性 = 今天的代码明天能改；可演化性 = 今天的架构能应对未知的未来变化
"可演化性 = 不需要重构" ——错。可演化性是长期目标，重构是持续活动——通过持续重构保持可演化性
"可演化性 = 加 feature 快" ——错。加 feature 快可能是可演化性好的表现，但不必然——关键看"应对未知变化"

关键洞察

可演化性 = capability（能变），不是 actuality（实际在变）。 SE@G Ch 1 的精确定义是 V2 B7 的核心："能变" 比 "实际在变" 更重要。 架构层（BC 边界 + 标准化接口 + OCP）+ 流程层（Deprecation + LSC + ADR）+ 组织层（Conway + Learning Org）——三件套共同构成可演化性。 控制论 Ch 18 不完备信息系统 + IDDD Ch 3 BC + SE@G Ch 1 可持续性 + EDM Ch 17 自然演化——四源汇成 B7 演化的工程定义。

Evolvability ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：度量可演化性 ​

场景 2：提升可演化性的工程实践 ​

场景 3：识别"可演化性失效" ​

场景 4：可演化性的反模式 ​

常见误区 ​

关键洞察 ​

相关链接 ​