不使用工作流引擎实现简单工作流
工作流引擎给系统开发带来了很多便利，让技术人员不用太关注业务流程控制，专注于业务逻辑实现，但它也带来一些问题。比如业务办理过程会产生数十倍的工作流数据，导致表空间占用过大；报表查询需要关联工作流中的信息，导致性能降低；工作流异常中止时，导致业务流程无法继续；缺少工作流专家，工作流问题难以解决；工作流引擎太重，多数简单流程用不上那么复杂的功能。
有没有办法在不使用工作流引擎的情况下，又能实现简单的工作流呢？我早几年看过前同事雄哥写的代码，那是一个带有工作流的自动任务。高手写的代码看起来赏心悦目，他用自己实现的简单工作流，把集中支付业务的财政报文校验、账务处理、结果报文组装发送、数据库更新的环节串起来了。自动任务开始一次轮询时，每一个后续环节处理类会根据数据库流程配置信息自动调起。不得不说，银行的软开牛人挺多的。
在我模糊的印象中，他是这么做的：它的处理流程是一个单项链表，数据库中配置好当前处理类对应的下一个处理类，从Start状态开始处理，代码中用getBean拿到下一个处理类实例，用反射调用方法传入参数，直到End状态，结束流程。
我们可以借鉴这个办法，用状态切换来实现一个简单的工作流。
首先定义一张业务状态表，把涉及到的业务状态编个码。
业务状态表的值域可能是这样的。
然后定义一张操作类型表，把所有可能的操作编个码。
操作类型表的值域可能是这样的。
接着定义一张流程配置表，放缓存里。存储的数据类似一张链表。
每种业务状态定义对应的方法，处理某个状态的业务。在业务逻辑处理完毕之后，根据区划代码、当前业务类型、状态和操作类型代码查询下一步的业务状态，更新业务数据状态，同时在业务数据中更新操作人和操作意见。另外用一张业务操作日志表，记录所有操作的过程信息。
这种处理方式，虽然在业务表中存放了操作信息的内容，属于反范式设计，但它能简单模拟工作流引擎最核心的功能，提升读性能，减少数据总量，业务处理类中也不用写死下一步要赋值的状态代码。更重要的是，它不依赖工作流引擎，完全可控。