163 lines
6.3 KiB
Markdown
163 lines
6.3 KiB
Markdown
# 前后端项目功能与开源组件可修改性分析报告
|
||
|
||
## 1. 分析范围与目标
|
||
- 前端项目：`F:/ips/node-test-mod`
|
||
- 后端项目：`F:/ips/java_test_back`
|
||
- 目标：
|
||
1) 分析前后端主要功能定位与模块职责
|
||
2) 重点分析前端关键页面涉及的核心组件是否开源、是否可修改
|
||
|
||
> 本次分析在 `glm47` 模型下完成。
|
||
|
||
---
|
||
|
||
## 2. 前端项目（node-test-mod）分析
|
||
|
||
### 2.1 技术栈与架构特征
|
||
- 框架：Vue 3 + Vue Router + Pinia
|
||
- UI：Element Plus
|
||
- 图编辑/流程建模：LogicFlow（含官方包与定制命名空间包）
|
||
- 构建：Vite（并保留 Vue CLI 启动脚本）
|
||
- 通信：Axios
|
||
|
||
项目路由显示目前核心入口页面为：
|
||
- `/` -> `plan-simulation-modeling/index.vue`
|
||
|
||
这说明该前端的主业务是“工艺/产线/计划仿真建模与生产控制配置”的单页主工作台。
|
||
|
||
### 2.2 页面功能拆解（核心页面）
|
||
根据目录结构，核心页面由以下子能力组成：
|
||
|
||
1. **Diagram 图形建模区**
|
||
- 文件：`components/Diagram.vue` 与大量 `components/node/*`
|
||
- 功能：节点、连线、箭头、图元、图标、路径图形的绘制与编排
|
||
- 特征：包含大量自定义 Node/Edge，实现行业场景图元（仓储、工艺段、生产单元等）
|
||
|
||
2. **左侧建模工具/资源面板**
|
||
- 文件：`left-sidebar-config/*`
|
||
- 功能：不同建模域（如 PHMM / PRCM）的图元选择与配置入口
|
||
|
||
3. **顶部工具栏**
|
||
- 文件：`top-sidebar-config/DiagramToolbar.vue`
|
||
- 功能：缩放、回退、前进等画布操作，流程编辑辅助
|
||
|
||
4. **属性面板（设备/连接/工艺属性）**
|
||
- 文件：`equ-attribute-config/*`
|
||
- 功能：不同实体（设备、线段、仓库、关系链接等）属性编辑
|
||
- 特征：按类型拆分细粒度组件，适合扩展复杂业务属性
|
||
|
||
5. **生产控制配置（多维控制）**
|
||
- 文件：`production-control/*`
|
||
- 功能：区域、线、段、单元、组合仓等控制策略配置
|
||
|
||
6. **TOB 生产相关页面**
|
||
- 文件：`tob-production/*`
|
||
- 功能：切批、仓储生产、单元生产等业务规则配置
|
||
|
||
7. **API 分层清晰**
|
||
- 文件：`src/api/*`
|
||
- 分类：生产控制、工艺路线、TOB 生产、仿真包配置等
|
||
|
||
### 2.3 前端项目总体判断
|
||
这是一个“行业仿真建模 + 生产控制配置”的复杂业务前端，强图形编辑能力 + 强配置能力并存，属于中大型业务平台前端。
|
||
|
||
---
|
||
|
||
## 3. 后端项目（java_test_back）分析
|
||
|
||
### 3.1 架构与技术栈
|
||
- 多模块 Maven 聚合工程（`packaging=pom`）
|
||
- Java 8 + Spring Boot 2.3.12 + Spring Cloud Hoxton + Spring Cloud Alibaba
|
||
- 数据与中间件：MySQL、Redis、MyBatis-Plus、Druid
|
||
- 安全与接口：Spring Security、JWT、Swagger
|
||
|
||
### 3.2 模块职责（按命名与控制器分布）
|
||
- `business-common`：权限、字典、日志、监控、在线会话等通用能力
|
||
- `business-core`：仿真主流程、仿真项目、任务、统计、结果分析、记录
|
||
- `business-support`：基础主数据、工艺定义、日历、BOM、PHMM/PRCM 等业务支撑
|
||
- `business-mansch`：排产/调度（FIFO/FEFO 等版本）
|
||
- 其他：`application/config-*` 负责启动与配置
|
||
|
||
### 3.3 控制器规模（粗粒度）
|
||
- `business-common`: 8
|
||
- `business-core`: 15
|
||
- `business-support`: 42
|
||
- `business-mansch`: 2
|
||
|
||
说明后端侧重点是“业务支撑与配置域（support）+ 仿真核心域（core）”。
|
||
|
||
### 3.4 后端总体判断
|
||
后端是典型“仿真业务平台”的分层多模块实现：
|
||
- 通用安全与治理能力完善
|
||
- 业务实体与工艺模型 API 丰富
|
||
- 可支撑前端图形建模页面的复杂配置与数据回写
|
||
|
||
---
|
||
|
||
## 4. 前端关键组件开源与可修改性分析（重点）
|
||
|
||
### 4.1 关键组件与许可证结论
|
||
|
||
1. **vue**
|
||
- 许可证：MIT
|
||
- 是否开源：是
|
||
- 可否修改：可以（可 fork/patch；注意保留许可证声明）
|
||
|
||
2. **element-plus**
|
||
- 许可证：MIT
|
||
- 是否开源：是
|
||
- 可否修改：可以（常见方式：主题变量定制、二次封装、必要时 fork）
|
||
|
||
3. **vue-router / pinia / axios / sortablejs / preact**
|
||
- 许可证：MIT
|
||
- 是否开源：是
|
||
- 可否修改：可以（通常建议“封装优先、fork 兜底”）
|
||
|
||
4. **@logicflow/core / @logicflow/extension**
|
||
- 许可证：Apache-2.0
|
||
- 是否开源：是
|
||
- 可否修改：可以（允许商用与修改，需遵守 Apache-2.0 的 NOTICE/License 要求）
|
||
|
||
5. **@helinda-test-logicflow/core / extension**
|
||
- registry 元信息显示：Apache-2.0，仓库指向 LogicFlow
|
||
- 判断：大概率是对 LogicFlow 的“企业内镜像/定制包命名空间”
|
||
- 可否修改：
|
||
- 从许可证看可修改
|
||
- 但若该包由公司私有源维护，实际发布与版本管理权限受组织流程约束
|
||
|
||
### 4.2 关键页面组件可改性结论
|
||
- 页面中大部分“关键业务组件”（如 `src/views/plan-simulation-modeling/components/**`）是**你方项目源码**，可直接改。
|
||
- 外部依赖组件（Element Plus / LogicFlow 等）可改，但建议优先级：
|
||
1) **业务层封装扩展**（首选）
|
||
2) **patch-package 定点补丁**（次选）
|
||
3) **fork 并锁定版本**（最后手段）
|
||
|
||
---
|
||
|
||
## 5. 风险与建议
|
||
|
||
### 5.1 主要风险
|
||
1. **自定义图元代码量大，升级成本高**
|
||
- LogicFlow 主版本升级可能影响自定义节点/边行为
|
||
2. **双命名空间 LogicFlow 依赖并存**
|
||
- `@logicflow/*` 与 `@helinda-test-logicflow/*` 并存，需防止能力重复或行为不一致
|
||
3. **历史版本目录较多（an-old-version）**
|
||
- 维护与排查时容易引入混淆
|
||
|
||
### 5.2 建议动作（可执行）
|
||
1. 建立“关键依赖白名单 + 许可证台账”（MIT/Apache-2.0）
|
||
2. 对 LogicFlow 的自定义扩展抽一层 adapter，降低升级耦合
|
||
3. 清理或冻结 old-version 目录，避免新旧逻辑交叉
|
||
4. 针对生产控制与属性面板建立组件测试（快照 + 交互）
|
||
|
||
---
|
||
|
||
## 6. 最终结论
|
||
- 前后端功能匹配度高：前端负责“图形化建模与配置”，后端负责“仿真核心与业务支撑 API”。
|
||
- 前端关键组件从许可证层面看**基本均为开源且可修改**（MIT / Apache-2.0）。
|
||
- 需要重点管理的是：
|
||
1) LogicFlow 定制扩展的长期可维护性
|
||
2) 私有命名空间包（`@helinda-test-logicflow/*`）的发布流程与版本控制策略
|
||
|
||
结论：**可改、能改、建议以封装+补丁为主，fork 为兜底策略。**
|