通过保持变更局部性实现演进式架构

一个软件工程团队负责维护和优化其内部电子商务的结账流程。最近他们收到了一项看似微不足道的需求：允许客户在下单后更改收货地址。由于结账模块拥有相关界面、确认流程以及客户操作流程，所以从表面上看，这项工作似乎属于结账团队的职责范围。 但需求分析揭示了一条截然不同的决策路径。地址能否更改取决于仓库截单时间、欺诈规则、配送合作伙伴的操作规范、客服支持脚本、通知模板以及退款政策。虽然实现该功能的工作量可能不大，但如果不了解其他团队负责的决策逻辑，那么结账模块就无法安全地进行这项更改。 这就是边界漂移。地址修改请求虽然始发于结账环节，但该环节无法掌控所有能够决定变更是否安全的决策。保持变更局部性意味着要明确这些决策，并将其交由理解这些决策的团队负责：履约团队负责截单时间，反诈团队负责风险规则，客服团队负责客户承诺，而结账团队可以直接使用这些决策，无需针对每个请求重新进行探索。 图 1：恢复局部性可以获得所需的上下文可见性，并确保局部变更仅限于局部范围（图片由 ChatGPT 生成） 基于变更局部性的演进 演进式架构基于一个简单的假设：变更是常态，而非例外。架构设计的核心问题不仅在于“系统能否变更？”，更在于“是否有合适的团队能在掌握恰当背景信息的情况下实现这一变更？” 现代系统同时面临源于多个方向的变更：新法规、客户工作流、产品实验、人工智能赋能、运营限制以及市场变化。在规模足够大的情况下，几乎任何系统都会变更。更棘手的问题在于，变更能否保持一致性，使团队能够逐步发展某项能力，而无需每次都重建整个系统。 这种特性就是“变更局部性”。当负责某项业务能力的团队不需要重建整个系统，就能回答以下三个问题时，该业务能力就具备了局部性： 这里可以进行哪些变更？有哪些约定能保护邻近的代码？有哪些证据能证明该变更是安全的？ 清晰的领域边界、明确的约定、可观察的依赖关系以及平台支持，都能服务于这一检验标准。 局部性并不意味着孤立。关键在于均衡：进行变更所需的理解程度应该与变更的范围成正比。如果变更地址副本需要检出代码并理解整个配送模型，那么这种局部性就比较弱。如果修改地址策略需要协调履约团队以及反诈团队，那么这种协调或许是必要的，但应明确规定。 边界漂移破坏了变更局部性 边界是对哪些决策或组件应该共同变更的假设。它们也是关于变更应该被限制在何处的临时约定，可以反映特定时刻的业务状况。 边界可能发生漂移的常见情况包括： 产品可能扩展到相邻的能力域。团队可能拆分、合并或重组。平台团队可能接管原本由产品团队负责的职责。辅助性或外包能力可能成为业务核心。 因此，曾经可以确保变更安全的边界，可能会与业务当前所需的变更路径产生偏差。 起初，地址变更的边界可能与结账流程非常契合。客户可以在订单打包前编辑地址。结账流程负责界面、规则、确认邮件和仪表盘。像“允许在购买后 30 分钟内编辑”这样的变更，只需一个团队、一套测试用例和一次发布即可完成。 随后，业务方逐渐积累了经验。有些商品很快就会从仓库发出；有些地址会触发欺诈检查；有些配送合作伙伴需要比其他合作伙伴更早地收到配送指示；高级会员享有更灵活的服务；客服开始通过电话处理异常情况。每一项变更都有其合理性。但这些变更综合起来，改变了地址更改在不同订单履约阶段的含义。 系统当前所体现的边界与待实施变更所要求的边界之间的差距，即为“边界漂移”。换言之，决策权已经发生转移或变化，但系统架构却未随之调整。结账团队仍然负责地址变更请求和待办事项，而履约、反诈、客服和配送团队现在则负责决定该变更是否安全。 我们还可以以一家数字零售银行的软件工程团队为例。该团队负责开户流程。在上线之初，该银行仅提供一种简单的储蓄账户。该开发团队负责申请表、身份核查和欢迎通知等工作；职责边界划分明确。 随后，该银行通过增加贷款账户实现了业务扩展，同时构建了自主的信贷审批流程。该流程可自动提取并评估信用记录，仅将边缘案例交由人工审批员进行处理。全面支持活期账户则意味着需要打印、邮寄和激活借记卡。然而，为支撑新的金融产品而不断扩展和演变的合规规则，却导致更多的申请被标记为待审核，需要人工收集、核验大量的申请材料，这可能将决策时间从几分钟延长至数天。 开户团队仍然负责开户流程，并直接接收修改表单的请求；为了安全地进行更改，这要求开户团队掌握由承保、卡片发放和合规部门持有的非局部背景信息。从纸面上看，职责边界从未改变。但变更路径确实是发生了变化。 图 2：除非架构师进行干预，否则边界漂移可能会形成一个强化循环（图片由 ChatGPT 生成） 认知负荷即信号 在此语境下，认知负荷指的是团队为了准确地对系统进行变更，必须在脑海中平衡处理的业务、技术、运营和组织背景信息的总量。 对于地址变更功能而言，问题并不在于“涉及五个团队”。真正的问题在于，系统无法识别哪些决策至关重要、由谁负责，以及有哪些证据能证明该变更的安全性。如今，一个看似简单的请求，却要求团队重新梳理仓库时效、配送合作伙伴规则、欺诈例外情况、客服承诺以及退款处理流程。 还有其他类似的情况。某团队对一个看似简单的功能进行了评估，但在实施过程中却发现它涉及三个归属不明的系统。事后分析显示，恢复工作完全依赖于一位工程师，凭借他之前担任其他职位时积累的经验，记起了一个不明显的依赖关系。入门培训需要数月时间，因为进行安全推理所需的知识既没有体现在代码中，也没有体现在测试、文档或仪表盘里。一个仅 10 行代码的拉取请求却引发了多达 50 条评论的审查讨论，因为审核人员无法就哪种行为是正确的达成一致。 这些或许可以表明，当前的边界模型已经无法与变更结构相匹配。 当决策权与面向用户的结构分离时，这种漂移就更容易被察觉： 社会技术设计解释了这种漂移 边界漂移属于社会技术现象，因为同一症状很少仅由单一技术原因所引起。团队所有权、运营流程、平台设计以及机构知识也会导致边界发生变化。下文将通过地址变更的例子来阐释这一点。 图 3：边界漂移很少仅是技术层面的问题；它涉及技术、团队、流程和人员等诸多方面（图片由 ChatGPT生成） 技术 当共享平台消除了重复性工作却掩盖了决策过程时，这可能是技术漂移的征兆。一个物流平台可能会将承运商规则、仓库截单时间和配送承诺集中管理。这或许是一种合理的权衡，但结账环节仍然需理解“已无法更改”这一响应的具体含义：是已打包、已发货、因欺诈被锁定、已通知合作伙伴，还是涉及退款问题。技术漂移还隐藏在跨域的共享数据库中、未通过明确契约添加的运行时依赖项中、掩盖重要行为的平台抽象中，以及因可观测性缺失而迫使团队推断其无法直接观察到的影响之中。 团队所有权 团队职责归属方面的模糊性或混乱可能发挥了一定的作用。结账团队可能负责客户体验，仓储运营团队可能负责实物履约，反诈团队可能负责风险管理，而客服团队可能负责异常处理。在局部看来，每项职责划分可能都合情合理。但当职责划分与团队预期的演进不再匹配，或者当组织结构发生变化而系统拓扑结构却未随之调整时，问题便会显现。在这个例子中，没有明确哪个团队负责端到端策略。 流程 流程的演变（或缺乏演变），加上能力的演变，都可能导致流程偏离。在发生交付事件后，可能新增了一个审查步骤。客户支持脚本可能已经成为例外策略的实际依据。退款审批可能被