项目需要对各项服务的工单进行流转操作。于是自己实现了一个工作流模块。由于项目初期采用微服务架构，而bpm作为其中一个子模块独立存在。所以在设计接口时考虑尽量少的暴露调用的方法，而把工单流转的逻辑封装在方法内部，比如：仅提供一个approveOrder的方法完成工单的审批同意、审批驳回和取消，内部需要处理大量的逻辑判断。现在想想这样的设计十分不妥，首先逻辑复杂，大量的if else堆叠在一起不利于维护和阅读。第二，很多的服务在bpm审批流程之外还有其他的流程，例如待受理，办理中等所以不可避免在审批流程之外对审批流程中的工单状态进行查询。会导致多次重复查询。审批操作工单需要查询审批系统中的工单状态，审批流程之外依然有查询审批系统中工单的必要，比如获取申请人信息，审批人信息用于通知，获取工单状态判断当前工单是否可以受理（接口校验），审批流何时可以取消（审批的流程中还是审批流之外的流程中），何时可以关闭（审批驳回操作时，取消操作时，业务流程结束时）。因此在做审批接口设计时应该尽量简化内部的流程判断。可以考虑将一个approveOrder（同时包含同意、驳回和取消）方法拆分成同意，驳回，取消三个不同的方法简化内部的流程判断。可以多定义几种操作二少定义流程状态，泛化流程操作的覆盖范围，简化流程的操作。
随着项目需求的发展，渐渐感觉到，一个工作流程可以划分成审批流程和业务流程两个部分。审批流程在审批系统中流转，业务流程在业务系统中流转。为防止业务流程代码逻辑混乱，我觉得依然也有简化审批流程调用的必要。
网友评论