架构改进
一、定位设计压力 检查相关流程、模块边界、依赖与测试。在提出方向之前，先核对适用的架构指导与既有决策。 识别具体摩擦：同一条规则在多处维护、改动扩散到无关模块、归属不清、依赖循环，或使行为难以测试的边界。 将观察到的问题与预期需求分开。预期需求应基于已知需求或变更模式；点名会影响选择的假设。
二、选择有用的设计 将当前结构与能解决该摩擦的最小结构改进进行比较。考虑归属、依赖方向、清晰度、可测试性和迁移成本，并简要说明决定性权衡。 当抽象能为某条不变式提供唯一归属、表达领域概念、分离独立变化的关注点或隔离外部依赖时再引入；重复是证据，而非前提。 将因同一原因变化的行为归在一起。即便实现相似，也要让不同概念保持分离；避免用带开关的通用辅助函数处理无关情形。 优先使用显式边界与窄契约。仅当能解决已识别问题时才添加层、接口或模式，并结合项目技术栈与规模评估。 判断简洁性应看维护者必须理解和改动的代码，而非差异大小。当大型重构能消除重复工作或隐藏耦合时，整体上可能更简单。
三、渐进式改进 实施时，若收益明确且迁移适合当前任务，就顺手改进受影响的设计。除非请求的变更另有要求，否则保持行为与公开契约不变。 让每一步迁移后系统仍可用。职责与其调用方一起移动；在用途都处理完毕后删除被替换的路径。临时适配器需要有具体的移除条件。 当更广泛的重设计会改变产品行为、公开契约或超出授权范围时，将其单独处理。说明拟议的边界与收益，使下一步可评审。 在迁移过程中保留安全、校验、错误处理与性能约束。更新因新结构而失准的指导；在必要时按本地 ADR 惯例记录长期且不显而易见的决策。
四、检查结果 使用相关测试与项目要求的检查，验证受影响调用方与边界处的行为。 回到最初的摩擦：确认归属更清晰，或改动需要更少协调。移除只是转移复杂度的抽象。 问题解决即停止。报告所选权衡、验证情况与剩余迁移工作；不要把持续改进变成持续扩大范围。