【💰】关于审批流程的开发思路

6 条回复
40 次浏览

先祝大家新年快乐 🧧,在家没事干干私活。

目前有个系统是这种审核流程,想咨询大家一些开发的思路。平时 curd 习惯了,只会用 if 写,有没有什么好的设计思路和架构等。
包括不限于:1.前端如果配置和展示。2.数据库设计思路。3.后端设计模式,架构等。
目前想到的方案是,1.前端用树形 table 展示。2.后端手搓一个状态机维护

Phase(大流程)
├─ Node(小流程)
│ ├─ State(状态 1)-- 审核部门 1
│ ├─ State(状态 2)-- 审核部门 2
│ └─ State(状态 N)-- 审核部门 N
├─ Node
│ ├─ State
│ └─ State
Phase(大流程)
......

金币池
💰 416 金币

金币池金币数量会随着回复数量动态增加,回复有概率获得金币池中部分金币奖励。

前排打手
Guardian

审批流看做到啥程度,那种不变的基本就写死就可以了

那种可以配置的,就先写好状态机,统一状态流转接口,然后根据状态判断流转

比如:提交状态,审核状态,驳回状态之类的

在界面上配置节点的状态,和角色之类的

网上有很多教程应该,搜一下

OP

多谢回复,我这系统核心不是审批流程,我就是想要搞成后台可配置,灵活一些,方便后期扩展的那种。

六边形战士
Guardian

如果是简单点的那种,点对点的审核,就是可以做一个流程配置表,配置表存每种业务的审核步骤以及每个步骤可以审核的角色
一个流程表,业务发起和每次审核后,从配置表中获取下一步的配置,重新生成下一步的审核记录,这种应该是最最最简单的了。
如果涉及到会签/或签,老老实实上工作流吧

马上来

前端树形 Table 只能做单向数据流吧?遇上一些复杂的审批流程可能就 G 了?
P.S. 更好奇为什么 op 标题能带双重金币池标记?手动复制的么

发表一个评论

R保持