
这篇文章,可能没有太多的干货,只是对于自己做过项目的一个反思与整理,同时,让这篇文章暴露在公共视野,虚心接受批评指导,向各位前辈同仁进行学习。
如果此文又不当之处,逻辑有问题的地方,设计不合理的地方,希望各位进行批评指正
主表设计
| 字段 | 名称 |
|---|---|
| id | 主键id |
| applicant | 申请人 |
| apply_time | 申请时间 |
| step | 审批进度 |
| status | 审批状态 |
| comment | 审批意见 |
| revoke_time | 撤回时间 |
副表设计
| 字段 | 名称 |
|---|---|
| pid | 审批主表主键id |
| user_id | 审批人 |
| approve_time | 审批时间 |
设计相应的接口来实现审批流程的功能。例如,可以设计以下接口:
实现相应的业务逻辑,如多人审批、撤回等功能。例如,可以采用以下策略实现多人审批功能:
所有的审批只有申请人和审批人可见
当审批被驳回,客户可通过修改进行二次申请
审批人进行审批,更改主表数据状态,在副表插入数据
涉及到二级审批,依然审批人进行审批,更改主表数据状态,在副表插入数据
最后的数据展示获取副表审批记录和申请人,进行数据过滤
在设计中,确保审批流程具有一定的灵活性,以适应不同业务场景。考虑是否允许在审批流程中动态添加或删除审批人,以便在流程进行中灵活应对变化。这可以通过设计支持动态审批人的接口和功能来实现。
除了主表和副表中的基本审批信息外,考虑是否需要更详细的审批日志记录。具体记录每位审批人的操作,包括操作类型(同意、拒绝、撤回等)、操作时间等信息。这样的详细记录有助于审批流程的追溯和审计,确保审批记录的完整性。
实现一个强大而灵活的通知机制,确保在审批流程的各个阶段都能及时通知相关人员。可以通过邮件、短信或系统内消息等多种方式进行通知。考虑设计通知模板,以便在通知内容需要调整时能够方便地进行修改。
审批状态目前包括“已通过”和“已拒绝”,但在一些场景下可能需要更多状态。考虑扩展审批状态,例如“待审批”、“审批中”等,以满足更多业务需求。确保系统设计能够轻松扩展和定制审批状态,以适应不同的业务流程。
在数据权限方面,确保只有申请人和相关审批人能够查看相应的审批记录。对于二次申请,设计一个灵活的机制,允许客户通过修改已有的申请进行二次申请,同时保留相关的审批历史记录。
对于涉及二级审批的情况,优化数据展示方式。可以考虑在界面上清晰地展示主表和副表的关联关系,以及审批人的操作记录,以便用户能够直观地了解整个审批流程的进展和历史。