如何进行业务重构
当一个业务功能不断增加能力时，问题通常不在于内容变多，而在于不同变化逐渐共享了状态、规则和处理流程。此时，新增一个小需求也可能影响多个模块。
重构要解决的不是某个局部是否整洁，而是如何重新组织职责和依赖，让需求变化停留在正确的边界内。
重构目标
重构的核心目标是缩小变化半径，也就是减少一次需求变化实际影响的范围。
一个合理的重构结果应该满足下面几点：
- 不同变化轴有明确的职责归属；
- 状态由真正产生变化的模块管理；
- 数据获取、数据转换、业务规则和流程编排彼此分开；
- 模块之间通过稳定的输入、输出或事件协作；
- 新增需求只改动对应的职责模块，规则验证也只覆盖该模块。
文件数量和层级深度只是结构变化的结果，不能单独作为重构是否成功的标准。
目标结构
可以先把系统抽象成输入、模块、流程和结果四个层次。
下面的关系图对比了当前结构和目标结构：当前结构中，多个变化来源直接进入共享状态；目标结构中，变化先进入对应模块，再由流程层组织最终结果。
这套结构不要求所有层次都物理分离，而是要求职责和依赖关系清晰：
- 输入层负责外部数据和前置条件；
- 模块层负责业务状态和规则；
- 流程层负责组织多个模块的协作；
- 结果层负责校验后的转换和保存。
表单权限案例
假设系统中存在一个表单权限功能。管理员需要为不同页面和设备配置字段状态，并处理个性化页面、移动端 Web 视图、页面入参以及 PC 与移动端的一致性校验。
早期实现通常会把页面选择、权限配置和保存流程放在同一条协作链路中。功能较少时，这样做成本较低；随着需求增加，页面结构、字段规则、参数映射和保存校验开始共享状态，新增一个小需求也可能牵动整个配置流程。
这个案例的关键不是配置项有多少，而是它包含了多条变化轴。
如果这些变化都由同一个模块管理，页面规则、字段规则和保存规则就会互相影响。重构需要做的是让变化轴和职责边界重新对应起来。
如何设计业务重构
划分职责边界
根据表单权限的变化轴，可以划分出下面几个相互协作的模块和一个配置流程：
这些模块不一定需要独立实现，代码可以合并，但职责和状态归属不能合并。
明确状态所有权
状态应归属于产生它的模块。页面选择状态由页面选择模块管理，页面结构状态由页面模型管理，字段状态由权限模块管理，参数映射结果由参数模块管理，PC 与移动端的比较结果由校验模块管理，保存状态由配置流程管理。
配置流程可以组合这些状态，但不应直接修改其它模块的内部状态。跨模块变化通过明确的输入、输出或事件完成。
控制依赖与协作方式
配置流程统一编排页面选择、参数处理、权限编辑、校验和保存。各模块只依赖完成自身职责所需的输入，只对外提供完成协作所需的结果，不读取其它模块的内部状态。
页面选择模块不需要了解字段权限规则，权限模块也不需要了解页面数据的获取过程。
如何执行业务重构
表单权限的重构可以按下面的顺序推进：
- 梳理现有职责、变化轴和依赖关系，建立共同的系统模型；
- 找出变化频繁且影响范围最大的耦合点，确定第一批重构边界；
- 先分离页面数据转换、权限规则和一致性校验；
- 调整状态所有权，让页面、权限和校验状态回到各自模块；
- 重新整理模块之间的依赖方向和协作方式；
- 调整展示和交互，让界面围绕已经明确的权限能力组织；
- 用后续需求验证边界是否稳定。
这个顺序的重点是先处理变化关系，再调整结构位置。直接移动实现只能改变位置，不能改变依赖关系。
重构也不一定一次完成。可以先稳定输入和输出，再逐步替换内部实现。每一步都应该保留已有行为，并明确验证范围。
如何验证重构结果
验证重构是否有效，不看模块数量，而看后续需求能否沿着已划分的边界局部处理。可以从三个方面检查：
- 变化范围：新增页面筛选、字段规则或参数配置时，是否只影响对应模块；
- 依赖关系：模块之间是否通过稳定输入输出协作，是否存在跨模块读取状态；
- 验证成本：规则变化是否可以在受影响的模块内完成验证，而不是每次都覆盖整个配置流程。
总结
进行业务重构时，关键是完成三件事：
- 找到被共享状态、共享规则和共享入口绑定在一起的变化；
- 按变化原因划分职责边界，让页面、权限、参数、校验和流程各自承担清晰职责；
- 用后续需求验证变化是否能够落在正确模块。
重构的结果不一定是更多模块，而应该是更小的变化半径，让系统能够沿着清晰的边界继续演进。