如何设计一个简易的工单系统

需求背景

先来看看业务整体结构图

由于当前所在公司是做保险相关业务的，需要对接很多公司，下单的过程中，必须将数据成功传输到保险公司并得到返回才算成功，在这个交互的过程中，很容易因为保险公司系统处于升级，或者过于繁忙状态，或者其他原因，导致我们下单失败，所以我们需要一个系统来对这些承包失败的订单继续处理，重新承保或者退款。另外还有一些其他需要人工介入的操作，我们也需要将其视为一个工单来处理。

以单个工单任务为例

以承保失败为例

流程与状态确定

从业务流程可以看出，等待人工介入，是一个持续的过程，因此我们需要一个状态PENDING来将这个任务标记为待处理，后续处理完成之后，需要一个状态FINISH来标记这个任务已经完成。按照目前的情况来说，状态已经可以解决目前的问题了，但考虑到未来有些任务的处理过程可能也是一个持续的状态，习惯性地加了一个PROCESSING处理中状态。
所以对于一个工单任务来说，目前状态有3个 PENDING，PROCESSING，FINISH。

单个环节解析

确定了流程之后，我们进一步分析每一个关节

这个环节是流程的开端，我们需要记录状态和失败订单的关键信息(包含时间类型，失败的原因，事件具体信息，相关人员，时间等)，所以，我们需要一张t_task表来记录一个任务的元信息。

除了承保失败，我们可能还有其他的任务事件，因此，我们需要定义一个事件类型TYPE。

这个环节需要人工介入，所以我们就需要通知到相关的人员，可能需要对这个任务进行分配，这个可以根据具体需求来考虑。

由于我们公司有一些订单失败的修复，有些特殊情况开发人员自己提脚本修改了，所以我们引入了一个定时任务，检查相关的业务状态，来判定这个工单是否完成并结束。

这个环节涉及到处理，处理的方式非常多，针对每个事件，都有好几种处理方法，所以我们可以抽象出以下模型。

接口设计

从上面业务模型分析上看，可变的东西有时间的不同，处理方式的不同。其它流程大体一致，所以我们对这两个不同点进行抽象，抽象成两个模版方法。

模版方法定义

public interface TaskService {
   
    // 提交任务
    void submitTask(TaskSubmitReq taskSubmitReq);
    // 处理任务
    void operate(TaskOperateReq taskOperateReq