架构变更案例：演进式架构的实用工具

标题：架构变更案例：演进式架构的实用工具

URL 来源：https://www.infoq.com/articles/architectural-change-cases/

发布时间：2026-06-04T09:00:00+0000

Markdown 内容：

核心要点

• 架构变更案例扩展了架构决策记录（ADR）的思维模式，通过评估决策随时间推移可能发生的演变来增强架构适应性。
• 随着业务需求、技术和运行环境的变化，软件架构不可避免地会发生衰退。针对这些领域的架构变更案例可以帮助团队减轻变更带来的影响。
• 变更案例能够揭示隐藏的假设，并帮助团队评估变更的可逆性和成本。
• 架构实验提供经验数据，以指导架构权衡并减少推测性的设计争论。
• AI 生成的代码引入了围绕可复现性、可维护性和架构漂移的新风险，团队必须对此有所预见。

软件架构的一个重点是提高系统在整个生命周期内的可维护性。在许多情况下，这种努力在很大程度上是推测性的，因为它考虑的是本质上不确定的事件。人们很容易通过问一句“如果以后需要修改，这能有多难？”来忽视潜在未来变更的影响，但我们的经验告诉我们，这无异于自讨苦吃。

为了聚焦这种推测并减少团队在看似无休止的“假设”讨论上花费的时间，我们使用一种称为“变更案例”的方法。架构变更案例有点像水晶球，让你能够推演架构决策可能产生的结果。

虽然架构决策记录（ADR）记录了决策以及有时涉及的权衡，但它们是对决策的总结，而非作为替代方案调查的起点。变更案例阐明了一种可能的需求，但并不规定满足该需求的具体手段。

与架构变更案例不同，架构权衡分析方法（ATAM） 的目标是评估现有软件架构满足其当前质量属性需求（QARs）的程度。相比之下，架构变更案例旨在评估系统在未来可能需要如何演进。

什么是架构变更案例？

架构变更案例识别了对解决方案假设的潜在变更，这种变更可能会对其软件架构产生重大影响。变更案例不需要定义替代解决方案；其主要目的是阐明未来某个时间点发生变更的可能性，并概述可能的替代方案。这种方法支持应急规划，并可能鼓励设计灵活性以减轻变更的影响。其最终目标是评估软件架构的弹性。

一个架构变更案例可能包含以下信息：

• QAR（更高或更低）或业务论证中的潜在变更
• 变更的可能性（概率）
• 因假设被违背而需要更改的决策列表
• 任何潜在的解决选项
• 变更成本的预测，即撤销决策的成本。该成本可以使用“T恤尺寸”（S、M、L、XL 等）的数量级进行粗略估算。

架构变更案例也是分析更改架构决策影响的好方法，它通过阐明替代决策以及在原决策被证明不正确时撤销当前决策以实施替代方案的成本来实现这一点。

识别架构变更案例的来源包括用于识别潜在故障和可能导致灾难性失败的系统配置变更的“混沌猴子”类测试。另一种有用的技术是进行事前验尸评审，以考量系统架构可能如何失效。架构变更案例可以阐明这些变更，并帮助团队制定应对措施。

架构变更案例预见系统衰退

在实践中，许多软件架构决策似乎要么假设事物不会改变，要么假设可以阻止改变。这两种假设都不现实。系统所使用的技术、维护系统人员的技能，以及最重要的是系统运行的业务环境，都不可避免地会发生变化。持续架构和演进式架构等方法认识到了这些挑战。

架构变更案例帮助采用这些方法的团队表达潜在的变更。这可能包括 AI 模型的变更（例如概念漂移）、环境配置、组件和框架版本、安全威胁、带宽等等。变更案例还考虑了商业环境的变化，例如最小可行产品（MVP）因市场转变而失败或过时。

架构变更案例的实践应用

以一家大型保险公司为例，该公司成立了一家新的子公司，旨在通过提供创新产品来与更灵活的竞争对手抗衡。他们希望最初推出按需度假房屋租赁保险，这是一种短期、灵活的保险产品，可以通过移动应用程序随时开启或关闭。该产品的可用性最初将仅限于一个州。其目标客户群包括租用度假屋几天到几周的人，因为他们的财物通常不在房主保险的承保范围内。

公司管理层假设，复用母公司的承保、会计和理赔应用将有助于降低成本并缩短上市时间。他们决定采用 AI 编程智能体，以快速将 MVP 推向市场。

他们面临的潜在变更场景包括对 MVP 采用率的低估。根据初步使用统计数据，短期租户似乎非常青睐这款新产品所提供的灵活性，因此实际用户数量可能比最高预估高出 50%。这可能导致 MVP 遭遇可扩展性和性能问题。最小可行架构（MVA）需要迅速更新，在预留安全余量的前提下应对更高的业务量。

如果业务干系人希望将目标客户群扩展至房车（RV）和船只租赁者呢？母公司的承保系统恐怕难以支持这些风险类别。又或者，如果业务干系人希望新增一个保险法规截然不同的州呢？这一变更场景将考验解决方案的可维护性，以及其性能和可扩展性。

这些变更场景意味着团队可能无法继续复用母公司的承保系统。表 1 总结了团队收集的变更场景信息。

/filters:no_upscale()/articles/architectural-change-cases/en/resources/8table-1-1780317718852.jpg)

表 1. 按需房屋租赁保险 MVP 的变更场景信息。

架构变更场景是一种用于思考架构决策影响的工具。就像推演国际象棋中一步棋可能带来的后果一样，它们能帮助团队评估特定架构决策的优势与劣势。

/filters:no_upscale()/articles/architectural-change-cases/en/resources/1GettyImages-1191856584-1780317091885.jpg)

架构变更场景有助于预判未来的架构决策。

构建最小可行架构以支持最小可行产品部署时，面临的一个挑战是：需要将架构变更场景纳入 MVA 的成功标准之中，而不仅仅是将其视为解决当前业务问题的手段。

架构变更场景的分类

虽然上述示例主要关注功能性变更，但团队还需考虑其他类型的架构变更场景，包括：

• 外部系统接口变更，要求您的系统随之同步调整。
• 因需求变化、供应商整合或倒闭、开源项目终止等原因，导致初始选择不再可行，从而需要替换主要子系统。
• 基础设施变更，包括将计算资源迁移至其他数据中心或云端，以及影响延迟的网络变更等。
• 商业模式的重大变化，包括 MVP 失败或市场变化导致原有商业假设失效。
• 因外部因素导致的系统安全漏洞变化。

思考各类变更场景示例可以促使团队质疑既有假设，从而帮助评估系统未来是否需要变更。

何时定义架构变更场景

在以下情况下，团队应考虑创建架构变更场景：

• 引入重大依赖项
• 采用 AI 生成的代码
• 硬编码业务规则
• 为快速交付 MVP 进行优化
• 与外部平台耦合
• 接受可扩展性或可维护性方面的权衡

当未来撤销某项决策可能带来高昂成本或运营风险时，变更场景的价值最为显著。

架构变更场景与规划

定义变更场景非常适合融入迭代规划工作（例如 Scrum 中的 Sprint）。正如我们在之前的文章中所述，每个迭代都会产出一个新的或增强的 MVP 及其关联的 MVA。在规划迭代工作时，团队需要考虑正在做出的架构权衡，以及当业务、市场或质量属性需求（QAR）发生变化时，这些权衡可能如何随时间演变。

仅仅识别可能的变更场景可能就足够了，或者团队可能需要更进一步，通过实验来验证关于代码未来适应变更能力的假设。这些实验的结果将告诉团队，为了在未来需要时能够替换系统的某些部分，需要在提升代码模块化方面投入多少精力。

AI 与架构变更场景

鉴于人们对使用 AI 编程智能体生成至少部分 MVP 的兴趣日益浓厚，我们有必要通过创建针对 AI 的特定变更场景，来考量其对未来变更的潜在影响。几乎所有使用 AI 智能体生成代码的场景都存在这样的风险：AI 公司可能倒闭或被竞争对手收购。另一个风险是 AI 模型可能发生显著变化，导致生成的代码在未来无法复现。

为了让 AI 编程助手产出合格的结果，团队需要预先投入时间明确目标、编写规范（包括代码示例）并定义验收测试。这些工作产物比 AI 生成的代码本身更为重要。为降低 AI 模型变更带来的风险，一种有效的策略是建立并维护一个制品库，用于向 AI 助手提供上下文信息，包括需求、规范、设计文档、架构/设计模型、过往的架构与设计决策、数据、接口规范、代码片段以及验收测试。该制品库可使用 GitHub 等现有工具进行维护。

使用 AI 编程助手的团队应考虑定义以下变更场景：

• 用 AI 代理生成的代码替换现有系统的某些部分（例如微服务）。在这种情况下，你仍然主导和控制架构，但将具体实现细节交由 AI 处理。
• 使用不同的 AI 或所选 AI 的新版本创建新的 MVP。如果你完全依赖 AI 编程代理生成了整个 MVP（以及由此隐含的最小可行架构 MVA），你需要确认这些结果是否可复现。
• AI 生成代码所需对接的外部系统发生变更。大多数新系统都需要与其他系统集成，而这些外部系统必然会发生变化。AI 生成的代码必须具备应对这种变化的能力。

投入资源构建专门针对 AI 的变更场景及相关制品库，是为借助 AI 编程助手构建的 MVP 提供未来保障的有效途径。

架构变更场景需通过实证评估

仅仅识别出架构变更场景是不够的。虽然意识到潜在问题很有帮助，但仅靠思考无法准确评估问题的严重程度。真正的挑战在于切实理解问题的规模（即成本）；你不可能为了评估而构建整套替代方案。通过开展实验，可以在无需完整构建替代方案的情况下，为估算提供数据支撑。

正如我们在之前的文章中所述，设计架构实验是一项重要技能，有助于理解潜在变更的风险与复杂性，并验证假设。事实上，要真正理解变更的影响，唯一的方法就是尝试实施预期变更的一小部分，评估其有效性，衡量所投入的工作量，然后据此推演整体结果。

适应度函数可用于评估变更的有效性。适应度函数提供了一种度量手段，能够为受变更场景影响的质量属性需求（QAR）建立基准，并检验实验是否在不对系统其余部分产生负面影响的前提下，成功实现了预期的改进。例如，针对表 1 中的第一个变更场景“产品采用率被低估”，性能和可扩展性适应度函数可以评估实验性 MVA 是否能在不损害 MVP 可用性和可维护性的情况下，带来预期的 QAR 提升。

当然，运行这些实验是有成本的。架构变更场景虽是有用的工具，但应适度使用，因为它们在时间和资金上的开销都可能很高。但对于某些问题而言，获取答案的唯一途径就是构建（或生成）并测试一些代码。

结论

人们很容易认为软件架构是静态的，一旦定义便一成不变。如果真有这样的架构，我们也从未见过。所有架构都会发生变化，关键在于这种变化是主动规划的还是被动发生的。架构变更场景能够帮助团队在涉及变更时，更加审慎地做出架构决策。

事实上，软件系统的架构永远没有真正完成之时，因为其外部环境始终处于变化之中。使用 AI 编程代理往往会引入不易察觉的变化，从而加剧这一问题。为应对这些变化压力，团队需要考虑构建能够持续预见并缓解变化的架构。采用架构变更场景可以为此提供有力支持。

关于作者

#### Pierre Pureur

Pierre Pureur 是一位经验丰富的软件架构师，在创新和应用开发领域拥有深厚背景，对金融服务行业有广泛了解，具备丰富的咨询经验和全面的技术基础设施知识。他曾任一家大型金融服务公司的首席企业架构师，负责领导大型架构团队、管理大规模并发应用开发项目、指导创新计划，并制定战略与业务规划。他是《实践中的持续架构：敏捷与 DevOps 时代的可扩展软件架构》（2021 年）和《持续架构：敏捷与云原生环境下的可持续架构》（2015 年）两本书的合著者，并已发表多篇相关文章，还在多个软件架构会议上就此主题进行过演讲。

展开更多 收起

#### Kurt Bittner

Kurt Bittner 在通过短周期、反馈驱动的方式交付可用软件方面拥有超过 30 年的丰富经验。他曾帮助众多组织采用敏捷软件交付实践，这些组织涵盖大型银行、保险、制造和零售企业，以及大型政府机构。他曾在 Oracle、HP、IBM 和 Microsoft 等大型软件交付机构任职或与其开展合作。此外，他还曾担任 Forrester Research 的技术行业分析师，并撰写了大量关于敏捷团队协作与领导力的文章。

展开 收起