143 lines
4.5 KiB
Markdown
143 lines
4.5 KiB
Markdown
|
# geMoldInsight 演进路线图（ROADMAP）
|
|||
|
|
|
|||
|
|
> 文档定位：**未来演进路线与阶段计划的权威文档**。
|
|||
|
|
> 本文回答“下一步准备往哪里演进、按什么阶段推进”；不负责维护当前实现状态，当前状态见 [STATUS.md](STATUS.md)。架构边界见 [ARCHITECTURE.md](ARCHITECTURE.md)，当前活跃技术债见 [TECH_DEBT.md](TECH_DEBT.md)。
|
|||
|
|
> 本文基于历史归档 [archive/EVOLUTION_ROADMAP.md](archive/EVOLUTION_ROADMAP.md) 收敛整理而来。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. 演进背景
|
|||
|
|
|
|||
|
|
geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台层 + 独立前端”的结构，但要让后续迭代成本继续下降，仍需要在以下方向持续推进：
|
|||
|
|
|
|||
|
|
- 继续收敛模块边界
|
|||
|
|
- 继续减少 shared 的历史耦合
|
|||
|
|
- 让部署、文档、契约与代码结构保持一致
|
|||
|
|
- 让 moldinsight 与 inventory 的协作关系更稳定、可维护
|
|||
|
|
|
|||
|
|
当前事实与最近完成项见 [STATUS.md](STATUS.md)。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 当前演进主线
|
|||
|
|
|
|||
|
|
### 2.1 主线一：模块化架构收口
|
|||
|
|
|
|||
|
|
目标：
|
|||
|
|
- 继续巩固 `moldinsight / inventory / frontend / shared` 的边界
|
|||
|
|
- 减少历史单体遗留语义
|
|||
|
|
- 让 README、架构文档、部署文档与代码结构一致
|
|||
|
|
|
|||
|
|
重点方向：
|
|||
|
|
- 继续收敛 `shared` 的职责
|
|||
|
|
- 逐步明确 identity / platform 的边界语义
|
|||
|
|
- 收敛历史文档与旧部署叙事
|
|||
|
|
|
|||
|
|
### 2.2 主线二：moldinsight 工程化增强
|
|||
|
|
|
|||
|
|
目标：
|
|||
|
|
- 让 STEP/STP 分析链路更稳定
|
|||
|
|
- 让导出、批量分析、成本估算、任务状态等链路更可靠
|
|||
|
|
- 继续提高 OCC 相关处理的可维护性与可测试性
|
|||
|
|
|
|||
|
|
重点方向：
|
|||
|
|
- `advanced_router` 拆分与请求模型规范化
|
|||
|
|
- 模具分析链路的结构继续收口
|
|||
|
|
- OCC 依赖场景下的契约测试/集成测试继续补齐
|
|||
|
|
|
|||
|
|
### 2.3 主线三：inventory 业务层继续沉淀
|
|||
|
|
|
|||
|
|
目标：
|
|||
|
|
- 让 inventory 从“可用”继续走向“可扩展”
|
|||
|
|
- 继续将路由中的业务逻辑下沉为 service 层
|
|||
|
|
- 保持与 moldinsight 的桥接模型清晰
|
|||
|
|
|
|||
|
|
重点方向：
|
|||
|
|
- 业务 service 复用强化
|
|||
|
|
- 数据模型归属进一步清晰化
|
|||
|
|
- 前后端契约持续减少手写漂移
|
|||
|
|
|
|||
|
|
### 2.4 主线四：部署与运维一致性
|
|||
|
|
|
|||
|
|
目标：
|
|||
|
|
- 让推荐部署模式、Compose 入口、运维文档、Nginx/端口说明不再冲突
|
|||
|
|
- 让前端、后端、异步任务链路在部署说明上形成单一叙事
|
|||
|
|
|
|||
|
|
重点方向：
|
|||
|
|
- 继续收口部署文档
|
|||
|
|
- 把历史部署迁移方案移入归档
|
|||
|
|
- 保持同域前端 + unified backend 的默认认知清晰
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 下一阶段优先项
|
|||
|
|
|
|||
|
|
### P0：文档与边界对齐
|
|||
|
|
|
|||
|
|
- 建立 `STATUS / ARCHITECTURE / ROADMAP / TECH_DEBT / DEPLOYMENT` 主骨架
|
|||
|
|
- 将 README 收敛为唯一导航入口
|
|||
|
|
- 收口部署重复文档并建立 archive
|
|||
|
|
|
|||
|
|
### P1：moldinsight API 结构整理
|
|||
|
|
|
|||
|
|
- 拆分 `advanced_router`
|
|||
|
|
- 为高频接口引入 Pydantic 请求模型
|
|||
|
|
- 继续减少 `request.json()` 风格手动解析
|
|||
|
|
|
|||
|
|
### P2：shared/platform 边界继续收敛
|
|||
|
|
|
|||
|
|
- 梳理共享 ORM 与业务模型的归属
|
|||
|
|
- 继续减少 shared 直接承担业务组合逻辑
|
|||
|
|
- 为后续平台层命名与目录调整准备条件
|
|||
|
|
|
|||
|
|
### P3：专项能力继续规范化
|
|||
|
|
|
|||
|
|
- 铝价模拟数据增加显式 `source: "simulated"`
|
|||
|
|
- 补专题文档的定位/边界说明
|
|||
|
|
- 清理历史 checklist / tasks / report 文档的展示层级
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. 中长期方向
|
|||
|
|
|
|||
|
|
### 4.1 平台层语义收敛
|
|||
|
|
|
|||
|
|
长期仍建议将 `shared` 逐步收敛为更清晰的平台层语义，但这应建立在：
|
|||
|
|
- 当前模块边界稳定
|
|||
|
|
- 共享职责分层足够清晰
|
|||
|
|
- 文档与部署已经同步收口
|
|||
|
|
|
|||
|
|
### 4.2 文档体系持续治理
|
|||
|
|
|
|||
|
|
后续文档治理原则：
|
|||
|
|
- README 只做入口
|
|||
|
|
- 当前状态只在 [STATUS.md](STATUS.md)
|
|||
|
|
- 历史材料统一入 `docs/archive/`
|
|||
|
|
- 每个主题只有一篇默认权威文档
|
|||
|
|
|
|||
|
|
### 4.3 测试能力继续增强
|
|||
|
|
|
|||
|
|
重点继续放在：
|
|||
|
|
- OCC 相关集成验证
|
|||
|
|
- 跨模块关键链路回归测试
|
|||
|
|
- 关键契约的自动化保护
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 4.4 专题文档持续分级
|
|||
|
|
|
|||
|
|
后续还会继续把专题文档区分为三类：
|
|||
|
|
- 当前仍有参考价值的专题文档（保留并补定位）
|
|||
|
|
- 纯阶段性任务/检查单/迁移计划（迁入 archive）
|
|||
|
|
- 可被主骨架吸收的重复说明（逐步收口）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. 与相关文档的边界
|
|||
|
|
|
|||
|
|
- 当前项目处于什么状态：看 [STATUS.md](STATUS.md)
|
|||
|
|
- 当前架构与边界是什么：看 [ARCHITECTURE.md](ARCHITECTURE.md)
|
|||
|
|
- 当前有哪些技术债：看 [TECH_DEBT.md](TECH_DEBT.md)
|
|||
|
|
- 当前部署方式怎么做：看 [DEPLOYMENT.md](DEPLOYMENT.md)
|
|||
|
|
- 更完整的模块化蓝图讨论：看 [archive/BACKEND_MODULARIZATION_BLUEPRINT.md](archive/BACKEND_MODULARIZATION_BLUEPRINT.md)
|