8.0 KiB
8.0 KiB
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 索引策略优化
四、实施计划
- 退出计划模式后，立即调用
/brainstorm技能，以本分析报告为基础材料 - 对 6 个专家组视角逐一展开头脑风暴
- 汇总所有专家建议，形成优先级排序的改进路线图
- 输出最终的 CRM 插件改进计划