交易平台审批流数据库表设计思路

背景介绍

        最近在开发一个交易管理平台，其中有一些涉及到平台账户打款给个人账户的场景如：

• 用户A和用户B确定交易后，平台会将用户A充值的钱转入用户B的账户。
• 用户A发起提现，平台会将钱转入用户A的账户

        这两处都是平台账户向用户账户转账，平台为了保证安全需要由财务人员进行审批（二级审批）后才调银行接口进行打款（充钱不用审批....）。

需求介绍

产品跟客户沟通后，大致需求如下：

1.多级审批，且是串行流程

        当前节点审批完成后，下一节点才能进行操作，例如试用员工转正流程需部门经理审批通过后，再由总监审批（除了串行流程还有并行流程和条件流程)。

简单介绍一下其他两种流程

并行流程：并行流程是指多个审批节点可以同时进行，不需要等待其他节点完成即可启动。这种模式适用于需要多人协作审批的场景。

条件流程：条件流程是指根据特定条件动态决定审批路径的流向。这种模式允许审批流根据实际情况灵活调整。

2.节点审批后需要通知发起人最新审批状态

        审批通过，审批不通过都要通知发起人，尤其是审批不通过需要告知不通过的原因，那个节点没通过等信息，便于发起人改进后重新提交。

3.流程结束条件为任意节点审批不通过或者全部节点审批通过

        例如提现时，审批人员发现余额不足（理论上不存在，在发起流程的时候就已经校验过了）驳回提现申请。

4.发起人可以撤销流程

        例如在用户AB确定交易后，任何一方在打款之前取消交易，则打款流程也会被动撤销。

5.可以看到审批记录，当前节点和后续还有那些节点。

        例如用户发起提现后，一段时间还未到账就问平台的客服，而客服就可以查看具体的审批信息然后告知用户。

6.审批列表需要展示该流程所有未审批的人

        例如刚刚发起流程则未审批人是流程所有节点的审批人，某个节点审批过后就去掉该节点的审批人。

表结构设计与字段说明

1.交易审批表

        交易审批表用于存储每笔交易（需要审批的交易）的审批信息，记录整个审批流的状态，审批人等信息。

字段名	数据类型	描述
ID	BIGINT	主键
PAYMENT_ID	BIGINT	交易ID
AUDIT_STATUS	TINYINT	审批状态（0-待审批，1-审判中，2-审批通过，3-审批驳回，默认待审批）
AUDIT_TIME	DATETIME	审批结束时间（审批通过或不通过）
TOTAL_AUDIT_USER	VARCHAR	总审批人（userId，可以多值）
NOT_AUDIT_USER	VARCHAR	总未审批人
USER_ID	BIGINT	发起人
COMMIT_TIME	DATETIME	发起时间
TOTAL_NODE	INT	总节点数
CURRENT_NODE_ID	BIGINT	当前节点
IS_CACEL	TINYINT	是否撤销(0-否，1-是，默认0)

说明：

• audit_statue字段用于控制全局状态
• total_node 和 current_node_id配合使用，可以直观展示当前进度。
• 除了业务字段还有创建时间，创建人，修改时间，修改人，逻辑删除等字段

2.审批节点表

        审批节点表定义了审批流中的每个节点及其审批人等信息。

字段名	类型	描述
ID	BIGINT	主键
NODE_NAME	VARCHAR	节点名称
NODE_LEVEL	INT	节点级别
NEXT_NODE_ID	BIGINT	下一个节点（0表示无节点，直接结束流程）
AUDIT_USER	VARCHAR	当前节点审批人(可以是userId，roleId)
AUDIT_CLASSIFY	TINYINT	节点类别(节点属于哪一个流程)
AUDIT_RULE	TINYINT	节点审批通过规则

描述：

• node_level字段确保审批流程按预定顺序执行。
• audit_classify字段标识当前节点属于哪一个流程
• audit_rule字段表示审批规则，如果存在某个节点是多个审批人的情况是只要一个同意就行，还是全部同意
• audit_user字段可以动态配置节点审批人员

3.审批记录表

        审批记录表用于记录每次审批操作的详细信息，确保审批过程可追溯。

字段名	类型	描述
ID	BIGINT	主键
AUDIT_ID	BIGINT	审批Id，关联交易审批表
NODE_ID	BIGINT	节点Id，关联节点表
AUDIT_USER_ID	BIGINT	审批人
AUDIT_STATUS	TINYINT	审批状态(2-通过，3-驳回)
REJECT_MSG	VARCHAR	审批驳回理由
AUDIT_TIME	DATETIME	审批时间
NOTIFY_STATUS	TINYINT	通知状态(0-未通知，1通知成功，2-通知失败）

描述：

• audit_use_id字段表示审批记录对应审批人，同一个节点多人审批一人对应一条记录。
• audit_status审批状态只有通过和驳回。
• audit_msg审批驳回必须记录理由。
• notify_status流程每次变化都要根据业务来决定是否通知发起人。

审批流程介绍

新增节点

        要使用审批流前提是维护审批节点信息即审批流程结构。

• 新增节点，名称，类别，级别
• 设置审批人，下一个节点

发起流程

        当一笔需审批的交易发起时，需要新增一条交易审批记录。

1. 获取提交人信息，提交时间
2. 获取当前属于什么类型流程
3. 根据流程类型查询除节点信息，包括总节点数，总审批人，当前节点等

审批流程

        当流程的某个节点的审批人处理后要记录审批信息并更新审批表中的记录，流程如下。

总结

        因为需要实现的审批流对应的流程比较简单所以只用了三张表，其中审批节点表就代表流程结构，如果是比较复杂的流程如条件流程，那么流程结构就不适合以这种形式维护可以用低代码流程编辑器来实现，前端提供一个可视化的界面来编辑流程结构方便又省事，编辑完后以Json格式导出流程结构信息在维护到数据库，审批时根据Json格式的流程信息来进行。