可修改性取决于变化落在哪里

系统“容易修改”并不意味着文件少或代码短。真正重要的是，一项预期变化需要理解多少上下文、触碰多少组件、协调多少团队，并承担多大的回归风险。可修改性是变化成本的属性，必须针对具体变化来讨论。

先描述可能发生的变化

新增一种内容类型、调整审核规则、替换地图服务商和修改页面颜色，所需的架构支持完全不同。若没有变化场景，“高内聚、低耦合”只能作为方向，无法判断某个边界是否合理。

变化场景通常包括变化来源、触发时机、被改动的制品、期望完成时间以及允许的副作用。频繁发生且业务价值高的变化，值得获得稳定扩展点；罕见变化若提前建设复杂框架，反而增加日常维护成本。

一个规则如果同时散落在数据库约束、后端判断、前端文案和部署脚本中，修改它就需要跨越多个所有权边界。传播范围越大，遗漏和不一致的概率越高。模块边界的价值，在于把共同变化的职责放在一起，并让外部通过清晰契约使用它。

减少依赖数量不是唯一目标。隐藏的运行时依赖、共享表和复制的常量，往往比显式接口更难管理。应同时检查编译依赖、数据依赖、部署依赖和团队协作依赖，判断一次变化真正要经过哪些路径。

封装可以把决策限制在一个模块内部，例如由统一的发布服务处理状态转换。但过早抽象会把尚未稳定的差异强行统一，使简单改动必须理解通用框架。是否抽象，应由已经出现或高度可信的变化模式支持。

配置可以降低重新编译和发布的频率，却会把复杂性移到校验、版本和运行时诊断。插件机制能够隔离实现，但也引入兼容契约与生命周期管理。每一种可修改性手段都在交换成本，不能只看增加扩展点的一面。

稳定接口不等于永不变化的参数列表。接口应该表达调用者真正依赖的语义，并避免暴露内部存储细节。若接口把表字段、内部状态或供应商概念直接泄露出去，内部调整会迅速变成跨系统变更。

兼容策略也属于可修改性设计。新增字段如何被旧客户端忽略，枚举怎样扩展，数据库迁移能否分阶段上线，都决定了变化是否可以独立交付。版本标识只是工具，关键仍是明确兼容范围和迁移期限。

架构评审可以选择几项近期可能发生的变化，逐项追踪代码、数据、测试、部署和文档的影响。若一个小需求必须修改许多无关区域，说明职责边界或契约存在问题。SEI 的早期架构分析强调在实现成本全面发生前，用场景暴露这些风险。

可修改性最终要通过历史数据观察：变更交付时间、受影响模块数、回归缺陷和跨团队等待时间都比主观的“架构很灵活”更可信。目标不是让任何变化都便宜，而是让重要且常见的变化落在可控制的位置。

Carnegie Mellon University Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/
Carnegie Mellon University Software Engineering Institute：Early Analysis of Software Architecture，https://www.sei.cmu.edu/library/early-analysis-of-software-architecture/