外观
实施路线
顺序是建议,按实际需求插入小步迁移,不暂停新功能开发。
| 阶段 | 工作 | 完成条件 |
|---|---|---|
| 1 边界定稿 | 确认 Gateway 的 AI 定位、五模块公开接口和数据归属 | 争议有决策,禁止新增的跨界依赖明确 |
| 2 当前短信收尾 | Mock 归属、发送入口、显式依赖、明细失败策略 | 新业务不绕过门面,既有路由和测发兼容 |
| 3 任务边界收紧 | Task 增加人工处置命令,Project 停止直接操作仓储 | 非法状态、重复操作和恢复经过任务服务 |
| 4 逐链迁移 | 选择一条旧项目生成链迁入 Task/Gateway | 参数、计费、结果、异常和旧任务兼容通过验证 |
| 5 持续收敛 | 依赖检查、日志接入、剩余旧链迁移 | 每次交付减少一项已登记债务 |
首批技术债:Task 仓储跨域暴露;Project 依赖供应商内部实现;新旧生成链并存;SMS 全局注入和 auth 反向依赖;凭证配置来源分散。详见各模块,不重复维护问题描述。
下一轮分析应列出所有外部消费者及跨模块写表位置,区分执行调用、类型引用和历史未使用代码。当前证据不足以给出工作日估时或宣布某模块重构完成。