优化
This commit is contained in:
+21
-7
@@ -24,11 +24,13 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 2.1 主线一：模块化架构收口
|
||||
|
||||
目标：
|
||||
|
||||
- 继续巩固 `moldinsight / inventory / frontend / shared` 的边界
|
||||
- 减少历史单体遗留语义
|
||||
- 让 README、架构文档、部署文档与代码结构一致
|
||||
|
||||
重点方向：
|
||||
|
||||
- 继续收敛 `shared` 的职责
|
||||
- 逐步明确 identity / platform 的边界语义
|
||||
- 收敛历史文档与旧部署叙事
|
||||
@@ -36,11 +38,13 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 2.2 主线二：moldinsight 工程化增强
|
||||
|
||||
目标：
|
||||
|
||||
- 让 STEP/STP 分析链路更稳定
|
||||
- 让导出、批量分析、成本估算、任务状态等链路更可靠
|
||||
- 继续提高 OCC 相关处理的可维护性与可测试性
|
||||
|
||||
重点方向：
|
||||
|
||||
- `advanced_router` 拆分与请求模型规范化
|
||||
- 模具分析链路的结构继续收口
|
||||
- OCC 依赖场景下的契约测试/集成测试继续补齐
|
||||
@@ -48,11 +52,13 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 2.3 主线三：inventory 业务层继续沉淀
|
||||
|
||||
目标：
|
||||
|
||||
- 让 inventory 从“可用”继续走向“可扩展”
|
||||
- 继续将路由中的业务逻辑下沉为 service 层
|
||||
- 保持与 moldinsight 的桥接模型清晰
|
||||
|
||||
重点方向：
|
||||
|
||||
- 业务 service 复用强化
|
||||
- 数据模型归属进一步清晰化
|
||||
- 前后端契约持续减少手写漂移
|
||||
@@ -60,10 +66,12 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 2.4 主线四：部署与运维一致性
|
||||
|
||||
目标：
|
||||
|
||||
- 让推荐部署模式、Compose 入口、运维文档、Nginx/端口说明不再冲突
|
||||
- 让前端、后端、异步任务链路在部署说明上形成单一叙事
|
||||
|
||||
重点方向：
|
||||
|
||||
- 继续收口部署文档
|
||||
- 把历史部署迁移方案移入归档
|
||||
- 保持同域前端 + unified backend 的默认认知清晰
|
||||
@@ -103,16 +111,18 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
> 2026-09-15 完成 moldinsight 后端设计审查，产出的具体治理批次是当前下一阶段最具体的执行计划。
|
||||
> 债务明细与逐项现状见 [TECH_DEBT.md](TECH_DEBT.md) §3（D5–D14）；本小节只描述批次、顺序与每批归属。
|
||||
|
||||
| 批次 | 主题 | 内容 | 对应债务 |
|
||||
|------|------|------|---------|
|
||||
| 批次 0 | 安全与诚实（0.5–1 天） | `/api/status/{task_id}` 补鉴权 + 任务归属校验；`pythonocc_available` 真实检测；bcrypt 超长密码拒绝；SECRET_KEY / RUSTFS_* 惰性校验补齐 | D5 |
|
||||
| 批次 1 | 部署正确性（1–2 天） | 主链路改走 RustFS（分派入参 `file_path` → `stp_file_id`，worker 按 object_key 下载解析）；compose 共享卷兜底（过渡）；alembic 移出 startup（`AUTO_MIGRATE` 开关）；OCC 镜像引入方式修正 + 依赖锁文件 | D6、D12、D13 |
|
||||
| 批次 2 | 任务一致性模型（2–4 天） | PG 为单一事实源、Redis 仅热缓存；去掉多进程内存回退；批量元数据入库；型腔失败标 failed；持久化事务边界收口 | D7、D8、D9、D11 |
|
||||
| 批次 3 | API 与代码结构（3–5 天） | `_safe_include` 失败显式化（/health 暴露缺失路由）；advanced_router 拆分 + Pydantic 请求模型；async 重计算统一 executor；StorageIntegrationService 拆分；配置治理 | D1、D14 |
|
||||
| 批次 4 | 架构演进（5 天+） | 共享 ORM 按模块拆分；OCC 吞吐方案设计先行；文档 / 契约同步 | D3、D10 |
|
||||
| 批次 | 主题 | 内容 | 对应债务 |
|
||||
| ------ | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
|
||||
| 批次 0 | 安全与诚实（0.5–1 天） | `/api/status/{task_id}` 补鉴权 + 任务归属校验；`pythonocc_available` 真实检测；bcrypt 超长密码拒绝；SECRET_KEY / RUSTFS_* 惰性校验补齐 | D5 |
|
||||
| 批次 1 | 部署正确性（1–2 天） | 主链路改走 RustFS（分派入参`file_path` → `stp_file_id`，worker 按 object_key 下载解析）；compose 共享卷兜底（过渡）；alembic 移出 startup（`AUTO_MIGRATE` 开关）；OCC 镜像引入方式修正 + 依赖锁文件 | D6、D12、D13 |
|
||||
| 批次 2 | 任务一致性模型（2–4 天） | PG 为单一事实源、Redis 仅热缓存；去掉多进程内存回退；批量元数据入库；型腔失败标 failed；持久化事务边界收口 | D7、D8、D9、D11 |
|
||||
| 批次 3 | API 与代码结构（3–5 天） | `_safe_include` 失败显式化（/health 暴露缺失路由）；advanced_router 拆分 + Pydantic 请求模型；async 重计算统一 executor；StorageIntegrationService 拆分；配置治理 | D1、D14 |
|
||||
| 批次 4 | 架构演进（5 天+） | 共享 ORM 按模块拆分；OCC 吞吐方案设计先行；文档 / 契约同步 | D3、D10 |
|
||||
|
||||
**执行顺序建议**：批次 0 与批次 1 的 D6（RustFS 主链路）先行——前者是确认的安全漏洞，后者是部署根本性缺陷，两者互不依赖、改动可控。其余按批次顺序推进，每批完成同步 STATUS / TECH_DEBT / API_CONTRACT。
|
||||
|
||||
> 进度：批次 0 / 1 / 2 已于 2026-09-16 完成（D13 的 pip 全量锁文件为批次 1 遗留项，随下次镜像构建补齐；D11 留待后续批次，正确性已由批次 1 共享卷兜底）；完成明细见 [STATUS.md](STATUS.md) 与 [TECH_DEBT.md](TECH_DEBT.md) §2.5–2.6。
|
||||
|
||||
---
|
||||
|
||||
## 4. 中长期方向
|
||||
@@ -120,6 +130,7 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 4.1 平台层语义收敛
|
||||
|
||||
长期仍建议将 `shared` 逐步收敛为更清晰的平台层语义，但这应建立在：
|
||||
|
||||
- 当前模块边界稳定
|
||||
- 共享职责分层足够清晰
|
||||
- 文档与部署已经同步收口
|
||||
@@ -127,6 +138,7 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 4.2 文档体系持续治理
|
||||
|
||||
后续文档治理原则：
|
||||
|
||||
- README 只做入口
|
||||
- 当前状态只在 [STATUS.md](STATUS.md)
|
||||
- 历史材料统一入 `docs/archive/`
|
||||
@@ -135,6 +147,7 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 4.3 测试能力继续增强
|
||||
|
||||
重点继续放在：
|
||||
|
||||
- OCC 相关集成验证
|
||||
- 跨模块关键链路回归测试
|
||||
- 关键契约的自动化保护
|
||||
@@ -144,6 +157,7 @@ geMoldInsight 已从历史单体逐步演进为“双业务模块 + 共享平台
|
||||
### 4.4 专题文档持续分级
|
||||
|
||||
后续还会继续把专题文档区分为三类：
|
||||
|
||||
- 当前仍有参考价值的专题文档（保留并补定位）
|
||||
- 纯阶段性任务/检查单/迁移计划（迁入 archive）
|
||||
- 可被主骨架吸收的重复说明（逐步收口）
|
||||
|
||||
Reference in New Issue
Block a user