软件架构的一个核心目标是提升系统在生命周期内的可维护性。在许多情况下，这种努力很大程度上具有较强的预判属性，因为它面对的本质上是不确定的事件。人们经常会问“倘若后续要整改此处，难度会有多大？”这类问题，忽视了未来潜在的变更所带来的影响，但经验告诉我们，这种做法终将埋下隐患。
为了聚焦这种预判分析并减少团队耗费在没完没了的假设讨论上的时间，我们采用了一种叫做变更案例（Change Case）的方法。架构变更案例如同预测用的水晶球，可帮助我们推演各项架构决策会衍生出怎样的潜在结果。
虽然架构决策记录（ADR）用于记录决策，有时也记录权衡，但它们仅对决策内容做汇总，无法作为备选方案调研的起始依据。变更案例能够明确一类潜在的需求，但不会阐述实现该需求的具体途径。
与架构变更案例不同，架构权衡分析方法（ATAM）的目标是评估现有软件架构对当前质量属性需求（QAR）的满足程度。与之相对，架构变更案例用于研判系统未来所需的演化方向。
什么是架构变更案例？
架构变更案例会识别针对方案假设的潜在变更，这类变更有可能对软件架构造成显著影响。变更案例不需要定义替代解决方案；它的核心作用是厘清未来发生变更的可能性，并概述可能的备选方案。这种方法能够辅助制定应急预案，促进设计灵活性，以此削弱变更带来的影响。它的最终目标是衡量软件架构的弹性。
架构变更案例可能包括以下信息：
质量属性需求的潜在变更（提升或下调）或是业务方案发生变更
变更发生的可能性（概率）
因原有假设失效、需要调整的相关决策清单
各类可选的潜在解决方案
变更成本预估，也就是撤销原有决策所需耗费的成本。这种成本可借助“T 恤尺码分级”（S、M、L、XL 等）按数量级做粗略估算。
架构变更案例也是分析架构决策变更影响的有效方法，通过阐明一个替代决策以及如果原有决策被证实不合理时，废止现有决策、落地备选方案所需投入的成本。
架构变更案例的来源包含“混沌猴子（Chaos Monkey）”测试，这类测试用于排查潜在故障与极易引发重大故障的系统配置变更。另一个有用的技术是进行预验尸评审（Pre-Mortem Review），预判系统架构有可能出现故障的各类情形。架构变更案例有助于梳理这些变更，并帮助团队制定应对措施。
架构变更案例预判系统衰退
在实际落地过程中，许多软件架构决策似乎假设要么事情不会发生变化，要么可以防止发生变更。这两种假设都不现实。变更在所使用的技术、维护人员的技能以及最重要的——系统运营的业务环境中——都是不可避免的。持续架构和演化架构等方法论就充分意识到了这类挑战的存在。
架构变更案例能够帮助采用上述方法论的团队梳理各类潜在变更，包括 AI 模型的变更（如概念漂移）、环境配置、组件与框架版本、安全风险、带宽等方面的变更。变更案例还考虑到了业务环境的变更，例如最小可行产品（MVP）失败或因市场变化而过时。
实践中的架构变更案例
以某大型保险公司新设子公司为例，这家公司计划推出创新产品，借此和运营模式更灵活的竞品展开竞争。他们初期打算上线按需度假房屋租赁保险，这是一款短期灵活险种，可以通过移动应用开启或关闭。该产品初期仅在一个州提供。产品的目标客群为短期租住度假房源（数天至数周）的人，这类人群的随身财物大多不在房主原有保险的保障范围内。
公司管理层设想复用母公司的承保、会计和理赔应用程序可以降低成本和缩短上市周期。他们选择使用 AI 编码智能体快速将 MVP 推向市场。
他们的潜在变更案例包括低估 MVP 的采用率。实际用户数量可能比预估上限高出 50%，因为根据初步使用统计，短期租赁者似乎十分青睐这种新产品带来的灵活性。因此，MVP 可能会遇到可扩展性和性能问题。最小可行架构（MVA）需要快速迭代升级，预留冗余容量以支撑更高的访问流量。
如果业务利益相关者希望将目标客户群扩展到包括房车和船只租赁者呢？母公司的承保系统可能无法处理这些风险类别。如果业务利益相关者希望增加一个保险法规差异显著的州呢？这个变更案例将检验这个方案的可维护性、性能与可扩展能力。
这些变更案例意味着团队可能无法再复用母公司的承保系统。表 1 总结了团队收集的变更案例信息。
表 1. 按需房屋租赁保险 MVP 的变更案例信息
架构变更案例是研判架构决策影响的工具。就像推演象棋落子后的可能后果一样，它能够帮助团队评估某项架构决策的利弊。
架构变更案例有助于预判未来的架构决策。
通过最小可行架构来落地最小可行产品的一个挑战是，架构变更案例需要被视为 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 在达成 QAR 优化目标的同时是否损害了 MVP 的可用性与可维护性。
当然，开展这类实验是有成本的。架构变更案例是一个有用的工具，但应该适度使用，因为它们在时间与资金方面都可能产生较高开销。但对于某些问题，想要得到结论，只能编写（或生成）并测试部分代码。
结论
人们容易想当然地认为软件架构是静态的，一经确定就随时间保持不变。我们从未见过一成不变的架构，所有架构都会发生变动。关键在于这种变化是有意还是偶然发生的。当架构决策会发生变更时，架构变更案例能够帮助团队更深思熟虑地对待他们的架构决策。
事实上，软件系统的架构永远无法真正定型，因为周围的世界总是在发生变化。使用 AI 编码智能体生成代码会引入隐性的变化，而这也加剧了这一问题。为了应对这些变更压力，团队需要考虑创建一种能够持续预判和缓释变更风险的架构，而架构变更案例可以为此提供帮助。
查看英文原文：https://www.infoq.com/articles/architectural-change-cases/
