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

一个软件工程团队负责维护和优化其内部电子商务的结账流程。最近他们收到了一项看似微不足道的需求：允许客户在下单后更改收货地址。由于结账模块拥有相关界面、确认流程以及客户操作流程，所以从表面上看，这项工作似乎属于结账团队的职责范围。

但需求分析揭示了一条截然不同的决策路径。地址能否更改取决于仓库截单时间、欺诈规则、配送合作伙伴的操作规范、客服支持脚本、通知模板以及退款政策。虽然实现该功能的工作量可能不大，但如果不了解其他团队负责的决策逻辑，那么结账模块就无法安全地进行这项更改。

这就是边界漂移。地址修改请求虽然始发于结账环节，但该环节无法掌控所有能够决定变更是否安全的决策。保持变更局部性意味着要明确这些决策，并将其交由理解这些决策的团队负责：履约团队负责截单时间，反诈团队负责风险规则，客服团队负责客户承诺，而结账团队可以直接使用这些决策，无需针对每个请求重新进行探索。

图 1：恢复局部性可以获得所需的上下文可见性，并确保局部变更仅限于局部范围（图片由 ChatGPT 生成）

演进式架构基于一个简单的假设：变更是常态，而非例外。架构设计的核心问题不仅在于“系统能否变更？”，更在于“是否有合适的团队能在掌握恰当背景信息的情况下实现这一变更？”

现代系统同时面临源于多个方向的变更：新法规、客户工作流、产品实验、人工智能赋能、运营限制以及市场变化。在规模足够大的情况下，几乎任何系统都会变更。更棘手的问题在于，变更能否保持一致性，使团队能够逐步发展某项能力，而无需每次都重建整个系统。

这种特性就是“变更局部性”。当负责某项业务能力的团队不需要重建整个系统，就能回答以下三个问题时，该业务能力就具备了局部性：

清晰的领域边界、明确的约定、可观察的依赖关系以及平台支持，都能服务于这一检验标准。

局部性并不意味着孤立。关键在于均衡：进行变更所需的理解程度应该与变更的范围成正比。如果变更地址副本需要检出代码并理解整个配送模型，那么这种局部性就比较弱。如果修改地址策略需要协调履约团队以及反诈团队，那么这种协调或许是必要的，但应明确规定。

边界是对哪些决策或组件应该共同变更的假设。它们也是关于变更应该被限制在何处的临时约定，可以反映特定时刻的业务状况。

平台团队可能接管原本由产品团队负责的职责。

因此，曾经可以确保变更安全的边界，可能会与业务当前所需的变更路径产生偏差。

起初，地址变更的边界可能与结账流程非常契合。客户可以在订单打包前编辑地址。结账流程负责界面、规则、确认邮件和仪表盘。像“允许在购买后 30 分钟内编辑”这样的变更，只需一个团队、一套测试用例和一次发布即可完成。

随后，业务方逐渐积累了经验。有些商品很快就会从仓库发出；有些地址会触发欺诈检查；有些配送合作伙伴需要比其他合作伙伴更早地收到配送指示；高级会员享有更灵活的服务；客服开始通过电话处理异常情况。每一项变更都有其合理性。但这些变更综合起来，改变了地址更改在不同订单履约阶段的含义。

系统当前所体现的边界与待实施变更所要求的边界之间的差距，即为“边界漂移”。换言之，决策权已经发生转移或变化，但系统架构却未随之调整。结账团队仍然负责地址变更请求和待办事项，而履约、反诈、客服和配送团队现在则负责决定该变更是否安全。

我们还可以以一家数字零售银行的软件工程团队为例。该团队负责开户流程。在上线之初，该银行仅提供一种简单的储蓄账户。该开发团队负责申请表、身份核查和欢迎通知等工作；职责边界划分明确。

随后，该银行通过增加贷款账户实现了业务扩展，同时构建了自主的信贷审批流程。该流程可自动提取并评估信用记录，仅将边缘案例交由人工审批员进行处理。全面支持活期账户则意味着需要打印、邮寄和激活借记卡。然而，为支撑新的金融产品而不断扩展和演变的合规规则，却导致更多的申请被标记为待审核，需要人工收集、核验大量的申请材料，这可能将决策时间从几分钟延长至数天。

开户团队仍然负责开户流程，并直接接收修改表单的请求；为了安全地进行更改，这要求开户团队掌握由承保、卡片发放和合规部门持有的非局部背景信息。从纸面上看，职责边界从未改变。但变更路径确实是发生了变化。

图 2：除非架构师进行干预，否则边界漂移可能会形成一个强化循环（图片由 ChatGPT 生成）

在此语境下，认知负荷指的是团队为了准确地对系统进行变更，必须在脑海中平衡处理的业务、技术、运营和组织背景信息的总量。

对于地址变更功能而言，问题并不在于“涉及五个团队”。真正的问题在于，系统无法识别哪些决策至关重要、由谁负责，以及有哪些证据能证明该变更的安全性。如今，一个看似简单的请求，却要求团队重新梳理仓库时效、配送合作伙伴规则、欺诈例外情况、客服承诺以及退款处理流程。

还有其他类似的情况。某团队对一个看似简单的功能进行了评估，但在实施过程中却发现它涉及三个归属不明的系统。事后分析显示，恢复工作完全依赖于一位工程师，凭借他之前担任其他职位时积累的经验，记起了一个不明显的依赖关系。入门培训需要数月时间，因为进行安全推理所需的知识既没有体现在代码中，也没有体现在测试、文档或仪表盘里。一个仅 10 行代码的拉取请求却引发了多达 50 条评论的审查讨论，因为审核人员无法就哪种行为是正确的达成一致。

这些或许可以表明，当前的边界模型已经无法与变更结构相匹配。

当决策权与面向用户的结构分离时，这种漂移就更容易被察觉：

结账团队可以局部变更、测试、发布并进行观察。

结账团队负责处理请求；仓库团队负责确定截单时间

地址变更策略的决策权分散到结账、履约、欺诈、客户支持和交付团队

截单时间、欺诈封禁、合作伙伴交接、支持承诺、退款规则

边界漂移属于社会技术现象，因为同一症状很少仅由单一技术原因所引起。团队所有权、运营流程、平台设计以及机构知识也会导致边界发生变化。下文将通过地址变更的例子来阐释这一点。

图 3：边界漂移很少仅是技术层面的问题；它涉及技术、团队、流程和人员等诸多方面（图片由 ChatGPT 生成）

当共享平台消除了重复性工作却掩盖了决策过程时，这可能是技术漂移的征兆。一个物流平台可能会将承运商规则、仓库截单时间和配送承诺集中管理。这或许是一种合理的权衡，但结账环节仍然需理解“已无法更改”这一响应的具体含义：是已打包、已发货、因欺诈被锁定、已通知合作伙伴，还是涉及退款问题。技术漂移还隐藏在跨域的共享数据库中、未通过明确契约添加的运行时依赖项中、掩盖重要行为的平台抽象中，以及因可观测性缺失而迫使团队推断其无法直接观察到的影响之中。

团队职责归属方面的模糊性或混乱可能发挥了一定的作用。结账团队可能负责客户体验，仓储运营团队可能负责实物履约，反诈团队可能负责风险管理，而客服团队可能负责异常处理。在局部看来，每项职责划分可能都合情合理。但当职责划分与团队预期的演进不再匹配，或者当组织结构发生变化而系统拓扑结构却未随之调整时，问题便会显现。在这个例子中，没有明确哪个团队负责端到端策略。

流程的演变（或缺乏演变），加上能力的演变，都可能导致流程偏离。在发生交付事件后，可能新增了一个审查步骤。客户支持脚本可能已经成为例外策略的实际依据。退款审批可能被纳入了独立的工作流。虽然发布治理、架构审查、事件升级和决策流程体现了过往的经验教训，但在产品发生变化后，它们也可能还延续着旧有的运营模式。

通常，经验丰富的工程师、运维负责人和支持经理会记得某些承诺为何不安全。这种记忆非常宝贵。但风险在于，人际关系和记忆可能会成为唯一可靠的集成层。虽然系统在部署拓扑上看着是解耦的，但在安全推理所需的隐性知识方面却仍然是紧耦合的。

没有任何架构风格或建模实践能无限期地保证局部性。定期重新评估所选定的边界是否仍然符合当前的变更路径，这一点至关重要。

恢复局部性首先要从一个实际的问题入手：这种变更应该落实在何处？我们致力于让每一项决策都落实在其所属的语境中，同时确保为安全实施变更所需的证据都能够跨越边界、清晰可见。

图 4：架构干预始于诊断，随后通过权衡取舍来重塑局部性（图片由 ChatGPT 生成）

重新分配会改变机制的所有权归属。如果多个团队反复实现相同的机制（如阈值计算、合作伙伴状态检查、通知发送、部署管道、基础设施配置、合规性框架或可观测性连接），那么平台或共享服务可能就会有所帮助。但不要默认将业务策略转移到平台中。平台可以负责机制和繁琐的工作；产品和领域团队仍然需对客户承诺拥有明确的决策权。

可见性决定了团队需要看到什么。对于负责进行变更的团队而言，某些约束条件必须可见：订单何时完成拣货、何时因欺诈问题会阻止某个地址、合作伙伴何时需要最终指令，以及支持团队能做出哪些承诺。信息公开可以表现为明确的责任归属、API 契约、契约测试、架构决策记录、服务目录、有意义的事件、仪表盘或升级流程。其目标是让负责能力演进的团队能够清晰地理解那些保障变更安全性的决策。

通过演练测试新方案能否在实际条件下保持变更的局部性。重新设计后，需要测试此前需要专家协调的场景。支持团队能否根据可见的策略解决已知的地址变更异常？结账流程能否在允许的范围内调整 VIP 客户的专属时段？当合作伙伴交接导致变更不安全时，团队能否及时察觉？事件处理、入门培训、架构审查和功能演示都能揭示该边界在实践中是否有效。如果每个现实中的例外情况仍然依赖于同一批专家，则就说明局部性尚未恢复。