共享核心与本地变化：多地区系统怎样演进

一个系统开始服务第二个地区、第二类客户或第二条业务线时，团队常陷入两难：继续复制一份，担心维护成本失控；立刻做成”统一平台”，又发现真实差异远比预想多。两头都有各自的教训。

两难背后，是系统还没分清什么已经稳定、什么仍在变化。

大一统与定制化是一条滑动变阻器

统一与定制不是二选一，而是一条随条件调整的滑动变阻器。基础能力牢固、领域知识清楚、业务模式稳定时，统一可以减少重复、让协作有共同语言；反过来，当业务仍在探索、地区差异很大，或团队尚未理解领域边界时，保留定制化往往更诚实。

问题不在于选哪一端，而在于能否随条件调整。一个预约服务早期允许不同场馆有不同流程，可能比立即抽象出”万能工作流”更安全；当取消、确认、通知等规则反复稳定出现，再抽出共享核心才有证据支撑。

假设一个预约服务先在一个城市运行，后来需要支持不同的营业时间、取消规则和提醒方式。账户、预约状态和基本通知流程可能是共享核心；当地规则、文案和审批流程则更适合放在明确的扩展层。

关键不是把所有内容放进同一份代码，而是让每个差异有清楚的位置。若每个地区都直接修改核心，长期会互相阻塞；若核心一开始就为所有想象中的变化设计，复杂度会先于价值到来。

抽象应当跟着重复且稳定的模式走。两个地区恰好相似，不等于已经找到领域模型；当相似需求连续出现、差异也能被命名时，再把它提炼成接口、配置或共享模块更可靠。

每次准备抽象时，先问四个问题：

如果答不清，先保留局部实现，比过早搭平台更安全。延迟抽象是在给正确的设计攒证据，不是放弃设计。

共享模块需要明确谁维护、谁能改、改动怎样评审。跨团队修改不是禁区，但应让模块负责人理解影响范围，让测试覆盖真正的共同路径。

早期复制并不总是坏事：它能让团队更快看见真正差异。关键是记录哪些规则重复出现、哪些差异有稳定名字。只有当相似需求连续出现，且差异能被清楚描述时，才值得提炼接口、配置或共享模块。

某团队为三类业务建立”万能配置中心”，希望所有差异都写进同一张配置表。半年后，规则组合只有少数人看得懂，新业务一有例外就向核心加开关。问题不是配置化，而是把流程差异误判成参数差异。团队后来保留稳定的账户与记录能力，把不同审批流程移到适配层；新场景先局部实现，重复出现后才讨论共享。

多地区系统的目标不是”代码只有一份”，而是让共享带来真实收益，让变化不伤害其他使用者。边界清楚、责任清楚，系统才有机会随地区和业务一起演进。好架构是让团队在变化时还能以合适的成本调整；能跟着事实移动边界，才算得上架构判断力。