现有一个审核业务，需要逐层流转审批；当前的做法是用一张表存储需要审核的业务数据，用一个字断枚举当前的审核状态，现在枚举状态达到40个，逻辑处理变得复杂并且难以扩展；这种纵向累加式做法是不可取的，请问有经验的前辈该如何处理此问题？
光阴似箭催人老，日月如移越少年。
用bpm來解決
如果不打算採用成熟的工作流引擎，我覺得可以這樣考慮：把流程節點從狀態裡剝離出來，你可以建立一張流程表，把關鍵的流程階段作為記錄定義下來，包括流程的上一步、狀態、下一步。用這張表來識別這個工作流程的流轉。這樣可擴展性也會比較好。
題主說的難以擴展的意思是不是因為狀態太多,並且狀態之間的轉換呈現網絡狀,導致修改狀態的代碼遍布了整個程序中,所以直接導致的結果是:最後沒人能理清狀態間轉換的關係,修改一個狀態的邏輯,改的地方遍布整個程序,導致風險很大。 所以我覺得如果狀態之間的轉換十分複雜的話,可以透過狀態機去解決,將狀態之間的轉換關係透過配置來解決,並且將狀態之間的轉換關係內聚到狀態機模型裡面。 具體可以參考我以前抽象過的一個狀態機模型:狀態機
用bpm來解決
如果不打算採用成熟的工作流引擎，我覺得可以這樣考慮：把流程節點從狀態裡剝離出來，你可以建立一張流程表，把關鍵的流程階段作為記錄定義下來，包括流程的上一步、狀態、下一步。用這張表來識別這個工作流程的流轉。這樣可擴展性也會比較好。
題主說的難以擴展的意思是不是因為狀態太多,並且狀態之間的轉換呈現網絡狀,導致修改狀態的代碼遍布了整個程序中,所以直接導致的結果是:最後沒人能理清狀態間轉換的關係,修改一個狀態的邏輯,改的地方遍布整個程序,導致風險很大。
所以我覺得如果狀態之間的轉換十分複雜的話,可以透過狀態機去解決,將狀態之間的轉換關係透過配置來解決,並且將狀態之間的轉換關係內聚到狀態機模型裡面。
具體可以參考我以前抽象過的一個狀態機模型:狀態機