现有一个审核业务，需要逐层流转审批；当前的做法是用一张表存储需要审核的业务数据，用一个字断枚举当前的审核状态，现在枚举状态达到40个，逻辑处理变得复杂并且难以扩展；这种纵向累加式做法是不可取的，请问有经验的前辈该如何处理此问题？
光阴似箭催人老，日月如移越少年。
用bpm来解决
如果不打算采用成熟的工作流引擎，我觉得可以这样考虑：把流程节点从状态里剥离出来，你可以建立一张流程表，把关键的流程阶段作为记录定义下来，包括流程的上一步、状态、下一步。用这张表来标识这个工作流的流转。这样可扩展性也会比较好。
题主说的难以扩展的意思是不是因为状态太多,并且状态之间的转换呈现网络状,导致修改状态的代码遍布了整个程序中,所以直接导致的结果是:最后没人能理清状态间转换的关系,修改一个状态的逻辑,改的地方遍布整个程序,导致风险很大。所以我觉得如果状态之间的转换十分复杂的话,可以通过状态机去解决,将状态之间的转换关系通过配置来解决,并且将状态之间的转换关系内聚到状态机模型里面。具体可以参照我以前抽象过的一个状态机模型:状态机
用bpm来解决
如果不打算采用成熟的工作流引擎，我觉得可以这样考虑：把流程节点从状态里剥离出来，你可以建立一张流程表，把关键的流程阶段作为记录定义下来，包括流程的上一步、状态、下一步。用这张表来标识这个工作流的流转。这样可扩展性也会比较好。
题主说的难以扩展的意思是不是因为状态太多,并且状态之间的转换呈现网络状,导致修改状态的代码遍布了整个程序中,所以直接导致的结果是:最后没人能理清状态间转换的关系,修改一个状态的逻辑,改的地方遍布整个程序,导致风险很大。
所以我觉得如果状态之间的转换十分复杂的话,可以通过状态机去解决,将状态之间的转换关系通过配置来解决,并且将状态之间的转换关系内聚到状态机模型里面。
具体可以参照我以前抽象过的一个状态机模型:状态机