Activiti/Flowable 工作流实战动态表单怎么设计再看 Redis 在业务系统里的 6 种用法很多人做工作流项目时注意力都会被流程图吸走。但真正让系统具备平台能力的往往不是 BPMN 画布而是两件事一件是动态表单怎么建模另一件是 Redis 到底怎么用才不只是“存个验证码”。这个项目里刚好把这两块都做出来了所以特别适合拿来聊一聊“工作流平台真正落地时后端应该怎么设计”。文章目录Activiti/Flowable 工作流实战动态表单怎么设计再看 Redis 在业务系统里的 6 种用法一、动态表单到底在解决什么问题二、这套项目里的动态表单核心是 4 张表2.1 sn_flow_formmanager表单主表2.2 sn_flow_formfield字段元数据表2.3 sn_flow_node_procdef_relation表单和流程节点绑定2.4 sn_flow_node_procdef_promission节点字段权限三、动态表单设计时我最看重的不是“拖拽”而是这 5 个点3.1 元数据和运行数据分离3.2 字段标识必须稳定3.3 options 一定要可扩展3.4 节点权限不能写死在前端3.5 动态表单系统要考虑代码生成四、这套项目里的 Redis不只是缓存而是多种业务能力的底座五、Redis 的第 1 种用法动态表单草稿缓存六、Redis 的第 2 种用法登录态与 Token 续期七、Redis 的第 3 种用法组织、角色、部门等热点基础数据缓存八、Redis 的第 4 种用法生成编码队列与事务失败回滚九、Redis 的第 5 种用法第三方系统 token 缓存十、Redis 的第 6 种用法长耗时任务进度缓存十一、如果让我总结 Redis 在业务系统里的边界我会这样分11.1 短生命周期临时态11.2 高频读取热点数据11.3 外部凭证和会话态11.4 可排队、可回收的业务辅助数据十二、如果让我继续优化这套动态表单 Redis 设计我会补什么12.1 给表单草稿加上用户维度12.2 给 Redis key 做更统一的命名规范12.3 给动态表单的 options 做版本兼容策略12.4 给编码回填和草稿缓存增加监控十三、总结一、动态表单到底在解决什么问题很多团队一开始做审批系统都是直接写死页面请假单一个页面报销单一个页面入库单一个页面出库单一个页面前期当然能跑。但只要后面业务越来越多你会马上遇到这些问题字段经常改同一张单在不同节点展示方式不同某些字段需要动态联动某些表单要支持子表、多表、组合表单某些按钮只给特定角色和部门显示这时候如果每改一次都去改前后端代码系统很快就会失去平台化能力。所以动态表单真正要解决的不是“拖拽一下很好看”而是把页面结构抽成元数据把字段规则抽成元数据把节点权限抽成元数据把表单和流程绑定关系抽成元数据这个项目的设计方向我认为就比较符合这个思路。二、这套项目里的动态表单核心是 4 张表2.1sn_flow_formmanager表单主表从实体SnFlowFormmanager能看到它管的是表单整体定义比如formNametableNamefieldlayoutformTypeallJsonversioncombinationappKey也就是说这张表不是存一条“页面名称”而已而是在管理一张表单的元数据总入口。尤其是这几个字段特别有代表性tableName表单最终落到哪张真实业务表allJson整个表单最终配置 JSONcombination是否组合表单fields表单字段集合这就说明它的定位已经不是普通后台配置表而是“低代码表单定义中心”。2.2sn_flow_formfield字段元数据表字段层面的配置主要在SnFlowFormfield里。它管的东西就非常细了formIdnamemodeltypedataTypelengthrequiredrulesoptionspageMenuListoperationMenuListsummaryType尤其是这几个字段非常关键model字段在业务表里的稳定标识type前端组件类型比如输入框、单选、人员选择、部门选择、日期等dataType数据库层的数据类型rules校验规则options复杂配置 JSONoptions在这类系统里非常重要因为很多高级能力都要挂在这里比如默认值远程字典联动规则关联表单编码规则权限控制按钮配置所以动态表单系统的关键不是有没有input、select组件而是有没有一套能不断扩展的字段元数据模型。2.3sn_flow_node_procdef_relation表单和流程节点绑定有了表单定义还不够你还得回答一个问题这张表单到底属于哪个流程、哪个节点这个项目里就是靠sn_flow_node_procdef_relation来做这件事的。从 Mapper 能看到它至少包含form_idflow_idflow_node_idcurrent而且ActZprocessMapper里也能根据formId反查流程绑定关系。这说明它不是把“表单与流程”简单硬编码在一段 Java 逻辑里而是单独建了配置关系。这一步非常值钱因为它决定了系统能不能做到同一个流程绑定多个表单不同节点切不同表单表单和流程独立演进2.4sn_flow_node_procdef_promission节点字段权限这个项目里还有一张我认为特别有代表性的表sn_flow_node_procdef_promission名字虽然有点长但作用很明确就是按“流程节点 字段”来配置权限。字段包括flowIdflowNodeIdfieldIdpromissionTypefieldPeroJson其中promissionType已经把节点权限拆得很清楚了0不使用1隐藏2可写3只读这才是审批系统里真正实用的表单权限模型。因为同一张单据在发起节点、审批节点、归档节点本来就不该是同一个交互态。三、动态表单设计时我最看重的不是“拖拽”而是这 5 个点3.1 元数据和运行数据分离表单配置应该放在sn_flow_formmanagersn_flow_formfield业务实例数据应该落在真实业务表比如cc_dckdcc_drkd不要把用户每次提交的数据也塞回表单配置 JSON 里那样后面会非常难维护。3.2 字段标识必须稳定项目里每个字段都有modelfieldKeyformId这说明字段不是靠标题名识别的而是靠稳定标识识别。这是必须的。因为标题名、中文名以后都可能改但数据库字段和逻辑引用不能乱。3.3options一定要可扩展动态表单做到后面最难的不是基础录入而是复杂配置。比如这个项目里你能看到关联字段映射人员/部门组件生成编码规则字典选项菜单按钮配置字段联动这些都说明options不是“附加信息”而是整个系统可扩展性的核心载体。3.4 节点权限不能写死在前端如果“某字段在审批节点只读”这种逻辑写死在前端页面里你很快就会遇到页面越来越多节点越来越多权限逻辑越来越碎而像这个项目这样放在sn_flow_node_procdef_promission里后面就更容易平台化。3.5 动态表单系统要考虑代码生成这个项目里还有一条很有意思的线就是表单不是只拿来渲染页面还会参与代码生成比如ServiceFileServiceControllerFileService都在围绕SnFlowFormmanager和SnFlowFormfield做处理。这说明它的目标不是“在线表单器”而是“低代码业务生成平台”。这个方向在企业项目里是很实用的。四、这套项目里的 Redis不只是缓存而是多种业务能力的底座很多人提到 Redis第一反应还是缓存热点数据但这个项目里Redis 的使用已经明显超过“普通缓存”了。我把它总结成 6 类。五、Redis 的第 1 种用法动态表单草稿缓存这个项目里在RedisConstant里直接定义了SN_FLOW_FORM_MANAGER_DRAFT:%s在SnFlowFormmanagerServiceImpl里还能看到两段很典型的逻辑addFormMessageCachegetDraftInfo它的行为也非常清楚保存表单草稿时先删旧 key再把表单 JSON 存入 Redis过期时间 86400 秒也就是 24 小时这类设计很适合下面这些场景表单还没正式发布用户配置到一半先离开动态表单设计器需要临时预览这不是简单缓存而是“草稿工作台”能力。六、Redis 的第 2 种用法登录态与 Token 续期在TokenUtils里这个项目会用 Redis 保存 token 缓存根据 token 取 Redis 中的认证值校验失败时重新签发重新设置过期时间同时在ShiroConfig里还能看到RedisCacheManagerRedisManager也就是说这套系统的 Redis 还承担了登录态续期认证缓存权限缓存这在企业系统里非常常见而且也很合理。因为认证这类数据读多写少生命周期明显对实时性要求高非常适合放 Redis。七、Redis 的第 3 种用法组织、角色、部门等热点基础数据缓存SysAuthCache这部分我觉得很典型。里面能看到很多基于 Redis 的访问方式比如当前用户部门部门信息缓存角色代码仓库权限字典值转换例如getDeptById:这样的 key用户当前部门缓存当前用户可见仓库集合这说明 Redis 在这里承担的是“热点基础数据加速层”。这类数据的特点就是查询频率高更新频率低很多业务逻辑都要反复用到如果每次都走数据库列表页和审批页会非常重。八、Redis 的第 4 种用法生成编码队列与事务失败回滚这是我觉得这个项目里最有“业务味”的一个用法。在GenerateCodeUtilN.rePushRedisRueue里能看到它在做一件很细的事某次保存业务失败后把已经占用的流水号重新塞回 Redis 队列这说明 Redis 在这里扮演的不只是缓存而是“可回收编码池”的角色。这种设计特别适合单据编号行号可重复利用的业务编码因为这类数据如果只存在数据库里失败回滚时恢复会更麻烦。而 Redis 队列模式处理起来就很自然先取号失败再回填防止号码浪费或乱序这就是典型的“Redis 参与业务一致性”的用法。九、Redis 的第 5 种用法第三方系统 token 缓存在MybatisInterceptor里这个项目还做了一个很实际的功能把外部系统调用所需的dataSynAppToken和dataSynUserToken缓存进 Redis。逻辑也很符合企业系统常见做法先从 Redis 取 token校验 token 是否可用可用就直接复用不可用就重新请求第三方接口再把新 token 写回 Redis并设置 TTL这类 token 缓存非常典型适合外部开放平台单点登录平台设备接口网关数据同步平台本质上是“把高成本、短时效的外部凭证放进 Redis 缓存”。十、Redis 的第 6 种用法长耗时任务进度缓存这个项目里还有一个很容易被忽略但很实用的细节。在ZxxxlrController里能看到DRJD:guid这样的进度 key。它本质上是在用 Redis 做导入进度长任务进度前后端轮询反馈这种场景特别适合 Redis因为它需要的是快速更新快速读取临时存在根本没必要专门落数据库。十一、如果让我总结 Redis 在业务系统里的边界我会这样分结合这个项目我认为 Redis 最适合做下面 4 类数据11.1 短生命周期临时态比如草稿进度临时票据11.2 高频读取热点数据比如部门角色仓库权限字典数据11.3 外部凭证和会话态比如登录 token第三方 app token用户 token11.4 可排队、可回收的业务辅助数据比如编码池序号池任务队列但我一般不会建议 Redis 去承担“唯一真实业务数据源”的角色。比如正式审批记录业务主表核心财务结果这些仍然应该稳稳放数据库。十二、如果让我继续优化这套动态表单 Redis 设计我会补什么12.1 给表单草稿加上用户维度现在草稿 key 里主要能看到表名和表单标识如果后续支持多人并行编辑或多人设计同类表单我会再加用户 ID应用 ID环境标识避免草稿冲突。12.2 给 Redis key 做更统一的命名规范这个项目里已经有很多 key 前缀了比如SN_FLOW_FORM_MANAGER_DRAFTgetDeptById:dataSynAppTokenDRJD:如果继续平台化我会统一成业务域场景资源标识三段式命名这样排查问题会更舒服。12.3 给动态表单的options做版本兼容策略因为options承载的能力越来越多后面一定会遇到老 JSON 不兼容新组件新字段缺默认值节点权限 JSON 演进这时如果没有版本兼容策略后面维护会很累。12.4 给编码回填和草稿缓存增加监控像这种业务型 Redis 用法一定要有监控key 数量TTL 分布回填失败次数外部 token 刷新次数否则 Redis 一旦出问题你会很难第一时间定位影响面。十三、总结很多人觉得工作流系统的核心是流程引擎我现在越来越不这么看了。真正能把系统拉开差距的是下面两块动态表单到底是不是元数据化的Redis 到底是不是用在了真正有价值的业务环节上结合这个项目我比较认可的一套思路是用sn_flow_formmanager和sn_flow_formfield管表单元数据用节点绑定表和节点权限表把表单接进流程用 Redis 处理草稿、认证、热点基础数据、编码队列、第三方 token 和任务进度如果只记一句话我觉得可以记住这句动态表单决定系统有没有平台化能力Redis 的用法决定系统有没有工程化细节真正成熟的工作流项目往往两者都不能少。