架构不是被"设计"完成的，而是被持续演进出来的。
演进式架构关注的不是"如何一次把系统做对"，而是：如何在不确定性中，持续做出可逆、可控、可验证的架构决策。
任何严肃的软件系统都隐含以下事实：
因此：
试图通过一次性设计“冻结未来”的架构，在逻辑上必然失败。
演进式架构是一种对不确定性的系统性应对策略。
以下场景，演进式架构的核心架构不在成立：
| 场景 | 不适用原因 |
|---|---|
| 系统生命周期极短（数月内退休） | 投资回收期短于投入成本 |
| 需求长期稳定（成熟领域） | 变化不发生，演进能力无价值 |
| 缺乏CI/CD基础设施 | 增量变更的低成本循环无法运转 |
| 组织不允许渐进式发布 | 小步变更优势无法发挥 |
| 团队缺乏模块化设计能力 | 无约束的"演进"比"不变"更有害 |
| 监管要求架构变更预先审批 | 与"最后责任时刻"决策冲突 |
原则：演进式架构解决的是"不确定性"问题。
从原理层抽象，演进式架构可以被刻画为以下公式：
演进式架构 = 变化 × 约束 × 反馈 × 可逆性
| 要素 | 含义 | 对应能力 |
|---|---|---|
| 变化 | 需求、技术、组织持续变化 | 演进驱动力 |
| 约束 | 防止系统无序生长 | 架构治理 |
| 反馈 | 用真实数据校验假设 | 架构验证 |
| 可逆性 | 降低错误决策的代价 | 风险控制 |
四要素形成相互支撑的闭环：
变化 ────→ 约束
↑ │
│ ↓
可逆性 ←── 反馈
| 关系 | 说明 |
|---|---|
| 变化 → 约束 | 环境变化驱动建立治理边界，防止系统熵增 |
| 约束 → 反馈 | 有约束才能衡量变化是否合理；无边界则反馈无意义 |
| 反馈 → 可逆性 | 真实数据揭示错误决策，触发可逆性机制发挥作用 |
| 可逆性 → 变化 | 降低返错代价后，系统才敢拥抱变化 |
| 反馈 → 约束 | 数据反馈可能要求调整约束力度（收紧或放松） |
| 可逆性 → 反馈 | 因可逆而愿意试错，获得更多有价值反馈 |
核心逻辑：变化是常态，约束是响应，反馈是校验，可逆性是保障。四者缺一则演进闭环断裂——无约束的变化导致混沌，无反馈的约束沦为教条，无可逆性的系统恐惧变化，无变化的反馈只是历史回溯。
演进式架构之所以区别于其他架构方法论，核心在于三点：
| 原则 | 传统架构 | 演进式架构 |
|---|---|---|
| 适应度函数即约束 | 靠文档约束 | 靠可执行的自动化测试，每次提交都验证，违规直接阻断 |
| 演进性是一级公民 | 可演进性作为隐式需求 | 演进性作为显式可测量的架构维度 |
| 增量验证代替一步到位 | 大爆炸式重构 | 小步验证，可拆分、可验证、可回退 |
适应度函数回答的不是"系统现在好不好"，而是"系统是否正在朝着允许的方向演进"。
人类无法一次性理解复杂系统的全部影响。不是避免变化，而是让系统始终保持调整方向的能力。
适应度函数是对架构演进自由度的可执行约束机制*。
它回答的是：
缺乏适应度函数等显式架构约束的演进，容易退化为：
功能驱动下的结构腐化。
原子适应度函数：
整体适应度函数：
触发式：
持续式：
适应度函数并非“越多越好”，而应围绕架构决策相关性构建：
架构治理的失败，往往源于错误地将非架构指标架构化。
演进能力并非单一维度支撑，而是技术、流程、组织、治理四层协同的结果。任意一层失效，演进闭环便会断裂。
技术层 ────→ 流程层
↑ │
│ ↓
治理层 ←─── 组织层
技术层决定系统能否被演进。
| 要素 | 作用机制 | 失效后果 |
|---|---|---|
| 模块化与耦合 | 高内聚低耦合使变化隔离在局部 | 变化蔓延至全系统 |
| 数据演进 | 模式版本化、只增不减、用新操作抵消旧操作 | 数据变更成为演进瓶颈 |
**架构模块之间的耦合度，决定了系统的演进上限。**演进能力，本质上是将变化限制在局部的能力。
数据库变更不可逆，因此通常采用**”用新操作抵消旧操作”而非回滚历史**。渐进式模式演进（扩张 → 迁移 → 收缩）是数据层可逆性的常见解法。
| 模式 | 适用场景 | 核心机制 |
|---|---|---|
| 绞杀者模式 | 整体替换风险过高 | 通过代理逐步替换，隔离风险 |
| 修缮者模式 | 新旧系统长期并存 | 新旧共存，避免一次性切换 |
| 扩张-迁移-收缩 | 接口与数据变更 | 扩张新接口 → 迁移数据 → 收缩旧接口 |
| 气泡上下文 | 复杂系统隔离试验 | 低风险试验区，数据隔离实现真正解耦 |
迁移的本质：在新旧系统并存期间控制复杂度转移的艺术。所有有效迁移模式都满足一个条件——允许系统在不完美状态下长期运行。
技术层解决”能不能”，流程层解决”怎么做”。
| 要素 | 作用机制 | 失效后果 |
|---|---|---|
| 增量变更 | 小步提交、可拆分、可验证、可回退 | 大爆炸式变更，风险不可控 |
| 假设驱动开发 | 提出可证伪假设，最小成本验证 | 盲目变更，缺乏方向 |
**人类无法一次性理解复杂系统的全部影响。**演进式架构拒绝”大爆炸式重构”。
假设并不等同于用户需求，而是对系统未来形态的可证伪判断。
流程层解决”怎么做”，组织层解决”敢不敢”。
| 要素 | 作用机制 | 失效后果 |
|---|---|---|
| 康威定律对齐 | 团队边界与模块边界一致 | 跨团队依赖阻塞演进 |
| 反向康威策略 | 按目标架构形态重组团队 | 组织结构持续侵蚀架构边界 |
| IT与业务一体化 | 业务目标与技术能力共同演进 | 技术演进偏离业务价值 |
| 团队间显式契约 | 接口协议、变更评审、SLA | 隐性依赖使模块边界名存实亡 |
| 子域差异化策略 | 稳定子域约束优先，动态子域灵活性优先 | 过度治理抑制创新，或治理不足丧失质量 |
任何系统都会反映出构建它的组织的沟通结构。若团队结构是”大锅饭”，再清晰的架构边界也会被隐性依赖侵蚀。
组织层解决”敢不敢”，治理层解决”往哪走”。
| 要素 | 作用机制 | 失效后果 |
|---|---|---|
| 适应度函数融入流水线 | 架构约束成为CI/CD门禁，持续执行 | 架构约束沦为文档，无人执行 |
| 系统思维机制 | 架构Guild等跨团队协调，防止局部最优损害全局 | 各模块独立演进，系统整体退化 |
当适应度函数进入 CI/CD 流水线后，架构不再依赖文档和评审，架构约束成为持续执行的事实。这标志着架构治理从”人治”走向”机制治理”。
局部最优≠全局最优。架构Guild等跨团队协调机制，防止各团队演进自己的模块却伤害系统整体演进能力。
这些反模式的共同点是：
它们在短期内看似高效，长期却持续侵蚀演进能力。
遗留系统与演进式架构是同一问题的两面：
| 视角 | 演进式架构 | 遗留系统现代化 |
|---|---|---|
| 定位 | 构建方法论 | 应对策略 |
| 起点 | 全新系统，从0建设 | 已有系统，修复或替换 |
| 目标 | 让系统具备演进能力 | 让系统重新获得演进能力 |
| 时机 | 系统建设前/中 | 系统已出现问题后 |
本质上：演进式架构是预防医学，遗留系统现代化是疾病治疗。
遗留系统之所以变成遗留，正是因为当初违背了演进式架构原则——模块化缺失、数据不可逆、组织僵化、约束沦丧。现代化策略本质上是演进式架构原则在存量场景下的实践延伸。
选择策略的关键不是技术先进性，而是：
风险、价值与组织能力的匹配度。
本框架整合自 Gartner、Microsoft 6R、Deloitte 等主流现代化框架（详见"关联内容"）。
从低风险到高风险：
| 策略 | 英文 | 说明 | 适用场景 |
|---|---|---|---|
| 退休 | Retire | 系统下线，数据归档 | 系统已无业务价值，继续运行成本高于收益 |
| 维持 | Retain | 不再投入新功能，保持运行直到自然淘汰 | 短期内无法迁移，且系统稳定运行 |
| 封装 | Encapsulate | 将遗留系统功能/数据封装为 API，供新系统调用 | 遗留系统仍有重要功能被外部依赖，或只能访问其数据库无法修改代码 |
| 平台迁移 | Replatform / Rehost | 将系统迁移到新基础设施（如云端），仅做少量适配 | 需要改变运行环境但暂不具备重构条件 |
| 重构 | Refactor / Rearchitect | 重建模块化结构，局部替换核心模块 | 系统架构已严重阻碍演进，但业务逻辑仍有价值 |
| 重写 | Rebuild / Replace | 从零开始重写，保留数据资产 | 遗留系统已无修复价值，业务需求无法通过重构满足 |
策略选择原则：封装风险最低、收益最低；重构与重写收益最高但风险成本也最高。