190 lines
8.0 KiB
Markdown
190 lines
8.0 KiB
Markdown
# CRM 插件深度分析 & 多专家组头脑风暴
|
||
|
||
## Context
|
||
|
||
CRM 插件 (`erp-plugin-crm`) 是 ERP 平台的第一个行业业务插件，也是 WASM 插件系统的标杆验证案例。它已完成了设计规格中的全部 3 个阶段（共 24 个任务），包含 5 个实体、9 个权限、7 种页面类型。现在需要从深度和广度两个维度进行全方位审视，发现改进空间、架构风险和演进方向。
|
||
|
||
---
|
||
|
||
## 一、CRM 插件全景画像
|
||
|
||
### 1.1 架构定位
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────┐
|
||
│ 前端 SPA │
|
||
│ PluginCRUDPage / Tree / Graph / Dashboard / │
|
||
│ Tabs / Detail / Admin — 全部 schema 驱动渲染 │
|
||
└────────────────────┬────────────────────────────┘
|
||
│ REST API (pluginData + plugins)
|
||
┌────────────────────▼────────────────────────────┐
|
||
│ Plugin Host (erp-plugin) │
|
||
│ service.rs → engine.rs → host.rs → dynamic_table│
|
||
│ data_service.rs → handler → module │
|
||
└────────────────────┬────────────────────────────┘
|
||
│ WIT 接口 (Host API 9 个函数)
|
||
┌────────────────────▼────────────────────────────┐
|
||
│ CRM WASM Guest (erp-plugin-crm) │
|
||
│ lib.rs (30行) — init/on_tenant_created/ │
|
||
│ handle_event 全部 no-op │
|
||
└──────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 1.2 数据模型 (5 实体)
|
||
|
||
| 实体 | 表名 | 字段数 | 用途 |
|
||
|------|------|--------|------|
|
||
| customer | plugin_erp_crm_customer | 15 | 客户主数据 (企业/个人) |
|
||
| contact | plugin_erp_crm_contact | 8 | 联系人 |
|
||
| communication | plugin_erp_crm_communication | 7 | 沟通记录 |
|
||
| customer_tag | plugin_erp_crm_customer_tag | 3 | 客户标签 |
|
||
| customer_relationship | plugin_erp_crm_customer_relationship | 4 | 客户关系 |
|
||
|
||
### 1.3 页面矩阵 (7 页面类型)
|
||
|
||
| 页面类型 | CRM 用途 | 复杂度 |
|
||
|----------|---------|--------|
|
||
| CRUD | 客户/联系人/沟通/标签/关系列表 | 中 (搜索/筛选/排序/视图切换) |
|
||
| Detail (Drawer) | 客户360度视图 | 高 (字段+嵌套CRUD+时间线) |
|
||
| Tree | 客户层级树 | 低 |
|
||
| Tabs | 客户管理入口 | 中 |
|
||
| Graph | 关系图谱 (Canvas手绘) | 高 |
|
||
| Dashboard | 统计概览 | 中 |
|
||
| Admin | 插件生命周期管理 | 中 |
|
||
|
||
### 1.4 权限模型 (9 权限)
|
||
|
||
两级权限体系：平台级 (`plugin.admin/list`) + 插件级 (`erp-crm.customer.list/manage` 等)
|
||
|
||
---
|
||
|
||
## 二、深度分析 — 六维度体检
|
||
|
||
### 2.1 架构健壮性 ⚠️
|
||
|
||
**优势：**
|
||
- Host-Guest 沙箱隔离，Fuel 资源限制，WASM panic 不影响主服务
|
||
- 延迟写入模式 (PendingOp) 保证事务原子性
|
||
- 乐观锁 + 软删除 + 多租户隔离
|
||
|
||
**风险：**
|
||
- **JSONB 外键完整性为零** — `contact.customer_id` 指向已删除客户不会被拦截
|
||
- **WASM Guest 价值极低** — CRM 插件 lib.rs 仅 30 行，3 个生命周期钩子全是 no-op，所有业务逻辑实际在 Host 侧的 data_service.rs
|
||
- **动态表 SQL 拼接风险** — 虽有 `sanitize_identifier()`，但 JSONB 查询构建器复杂度高
|
||
- **插件热升级策略缺失** — 版本升级时如何处理已有数据的 schema 变更？
|
||
|
||
### 2.2 数据完整性 ⚠️
|
||
|
||
**当前状态：**
|
||
- 无 DB 级外键约束（JSONB 字段无法使用 PostgreSQL FK）
|
||
- 无应用层 FK 校验（data_service.rs 的 create/update 不检查关联实体是否存在）
|
||
- 删除客户时不级联处理关联的联系人/沟通记录/标签
|
||
- `customer.parent_id` 的循环引用无检测
|
||
|
||
### 2.3 查询性能 🟡
|
||
|
||
**已做优化：**
|
||
- GIN 索引覆盖 searchable 字段
|
||
- tenant_id 索引
|
||
- Redis 连接缓存 (响应 2.26s → 2ms)
|
||
|
||
**潜在瓶颈：**
|
||
- JSONB 内字段排序 (`ORDER BY data->>'field'`) 无法使用 B-tree 索引
|
||
- 聚合查询 (`aggregate`) 对大数据量可能慢
|
||
- 关系图谱需要全量加载 customer + customer_relationship，前端 Canvas 渲染
|
||
- 无分页的树结构查询（前端全量加载后客户端构建）
|
||
|
||
### 2.4 安全合规 🔴
|
||
|
||
- **数据权限缺失** — 只有操作权限 (能否操作)，无数据权限 (能看到谁的数据)
|
||
- **搜索注入** — search 参数直接拼入 SQL ILIKE，需确认转义逻辑
|
||
- **权限 fallback 过宽** — `plugin.admin` 权限自动获得所有插件的所有操作权限
|
||
|
||
### 2.5 前端体验 🟡
|
||
|
||
**亮点：**
|
||
- 全 schema 驱动，零 CRM 专用前端代码
|
||
- visible_when 条件表单字段
|
||
- 时间线/表格视图切换
|
||
- Canvas 手绘关系图谱（无第三方库依赖）
|
||
- 嵌套 CRUD (Detail Drawer)
|
||
|
||
**不足：**
|
||
- 无看板视图（销售漏斗/客户跟进阶段）
|
||
- 无数据导入/导出功能
|
||
- 无批量操作
|
||
- 标签系统过于简单（无标签分组管理、无标签云）
|
||
- Dashboard 统计维度有限（只有计数+分组聚合）
|
||
- 树页面不支持拖拽排序
|
||
|
||
### 2.6 可扩展性 🟡
|
||
|
||
**平台能力沉淀：**
|
||
- 7 种通用页面类型可供未来插件复用
|
||
- 插件 manifest (TOML) schema 定义了完整的元数据规范
|
||
- 插件生命周期管理 (上传→安装→启用→禁用→卸载→清除)
|
||
|
||
**限制：**
|
||
- 页面类型有限 — 无日历、看板、甘特图、地图等业务常见页面
|
||
- WASM WIT 接口固定 — Host API 9 个函数，扩展需要修改 WIT + 双端重编译
|
||
- 插件间通信未实现 — 当前只能通过 EventBus 订阅系统事件，插件间无法直接交互
|
||
|
||
---
|
||
|
||
## 三、专家组头脑风暴议题
|
||
|
||
基于以上分析，建议从以下 6 个专家组视角展开头脑风暴：
|
||
|
||
### 专家组 1: 后端架构师
|
||
**焦点：** WASM 插件架构的真正价值在哪里？如何让 Guest 代码从 no-op 变成有意义的业务逻辑？
|
||
- Host API 的 db_query 为何不可用？如何修复？
|
||
- JSONB 动态表 vs 独立 schema 表的取舍
|
||
- 插件版本升级的数据迁移策略
|
||
- 延迟写入模式的局限性和改进
|
||
|
||
### 专家组 2: CRM 产品专家
|
||
**焦点：** 这个 CRM 能用吗？缺什么核心能力？
|
||
- 销售漏斗/商机管理缺失的影响
|
||
- 客户跟进提醒机制
|
||
- 数据导入/导出 (Excel)
|
||
- 客户画像/360度视图的完整性
|
||
- 与 ERP 其他模块 (进销存/财务) 的联动
|
||
|
||
### 专家组 3: 安全工程师
|
||
**焦点：** 数据权限、隔离性、合规风险
|
||
- 行级数据权限 (谁能看到哪些客户)
|
||
- JSONB 查询注入风险
|
||
- 插件 WASM 沙箱逃逸可能性
|
||
- 审计日志的完整性
|
||
- GDPR/数据隐私合规
|
||
|
||
### 专家组 4: 前端架构师
|
||
**焦点：** Schema 驱动 UI 的天花板和突破路径
|
||
- 复杂交互场景 (拖拽、批量操作、右键菜单) 的 schema 描述能力
|
||
- 看板/日历/甘特图等新页面类型的设计
|
||
- 大数据量下的性能优化 (虚拟滚动、懒加载)
|
||
- 插件自定义 UI 组件的可行性
|
||
|
||
### 专家组 5: 平台架构师
|
||
**焦点：** 插件平台的通用性和未来演进
|
||
- 插件间通信和协作机制
|
||
- 插件市场/分发的技术架构
|
||
- 插件依赖管理和版本兼容
|
||
- 多租户插件隔离的成本和安全性
|
||
|
||
### 专家组 6: 性能工程师
|
||
**焦点：** JSONB 动态表的性能天花板
|
||
- 百万级数据的查询优化策略
|
||
- 聚合查询的预计算/缓存
|
||
- 关系图谱大数据量下的前端渲染
|
||
- PostgreSQL JSONB 索引策略优化
|
||
|
||
---
|
||
|
||
## 四、实施计划
|
||
|
||
1. 退出计划模式后，立即调用 `/brainstorm` 技能，以本分析报告为基础材料
|
||
2. 对 6 个专家组视角逐一展开头脑风暴
|
||
3. 汇总所有专家建议，形成优先级排序的改进路线图
|
||
4. 输出最终的 CRM 插件改进计划
|