先祝大家新年快乐 🧧，在家没事干干私活。
目前有个系统是这种审核流程，想咨询大家一些开发的思路。平时 curd 习惯了，只会用 if 写，有没有什么好的设计思路和架构等。
包括不限于：1.前端如果配置和展示。2.数据库设计思路。3.后端设计模式，架构等。
目前想到的方案是，1.前端用树形 table 展示。2.后端手搓一个状态机维护
Phase（大流程）
├─ Node（小流程）
│ ├─ State（状态 1）-- 审核部门 1
│ ├─ State（状态 2）-- 审核部门 2
│ └─ State（状态 N）-- 审核部门 N
├─ Node
│ ├─ State
│ └─ State
Phase（大流程）
......
金币池金币数量会随着回复数量动态增加，回复有概率获得金币池中部分金币奖励。
多谢回复，我这系统核心不是审批流程，我就是想要搞成后台可配置，灵活一些，方便后期扩展的那种。
如果是简单点的那种，点对点的审核，就是可以做一个流程配置表，配置表存每种业务的审核步骤以及每个步骤可以审核的角色
一个流程表，业务发起和每次审核后，从配置表中获取下一步的配置，重新生成下一步的审核记录，这种应该是最最最简单的了。
如果涉及到会签/或签，老老实实上工作流吧
没有那么复杂，和你说的流程很相似。 我也是想看看大家的想法，怕自己搞出来后期屎山又不好维护
可以跟把具体需求更想法跟 AI 聊聊，现在的 ai 都很强大了，这种流程设计不在话下，一步一步带你实现都行
前端树形 Table 只能做单向数据流吧？遇上一些复杂的审批流程可能就 G 了？
P.S. 更好奇为什么 op 标题能带双重金币池标记？手动复制的么
本来金币池设置的 300，后来删了改成 500，然后就这样了。我还以为是 500 比较多就显示两个呢，哈哈。
基本就是单向的数据流，审核驳回从头开始，或者审核时候手动选择到哪一个节点。
好早好早之前写过，是固定的部门挨个审批，所以和你说的用 if 差不多。
给不了好的建议，顺便来学习一下。
一起学习，我也是想来学习一下的
插件模式？
我再来摸个奖，给我中啊
审批流看做到啥程度，那种不变的基本就写死就可以了
那种可以配置的，就先写好状态机，统一状态流转接口，然后根据状态判断流转
比如：提交状态，审核状态，驳回状态之类的
在界面上配置节点的状态，和角色之类的
网上有很多教程应该，搜一下