现有一个审核业务，需要逐层流转审批；当前的做法是用一张表存储需要审核的业务数据，用一个字断枚举当前的审核状态，现在枚举状态达到40个，逻辑处理变得复杂并且难以扩展；这种纵向累加式做法是不可取的，请问有经验的前辈该如何处理此问题？
光阴似箭催人老，日月如移越少年。
BPM を使用して解決してください
成熟したワークフロー エンジンを使用する予定がない場合は、次のように考えることができると思います。プロセス ノードをステータスから分離するには、プロセス テーブルを作成し、主要なプロセス ステージをレコードとして定義します。プロセスの上位段階と下位段階を含みます。この表を使用して、このワークフローの流れを特定します。これにより、拡張性も向上します。
質問者が拡張するのが難しいと言ったのは、状態が多すぎて、状態間の遷移がネットワーク状になっていて、状態を変更するコードがプログラム全体に広がるため、直接的な結果が発生するという意味ですか?状態間の遷移の関係を明確にしたり、状態のロジックを変更したりすると、プログラム全体に変更が生じ、高いリスクが生じます。 つまり、状態間の遷移が非常に複雑な場合は、状態間の遷移関係を構成によって解決でき、状態間の遷移関係をステート マシン モデルに統合できると思います。 。 詳細については、以前に抽象化したステート マシン モデルを参照してください: State Machine
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
BPM を使用して解決してください
成熟したワークフロー エンジンを使用する予定がない場合は、次のように考えることができると思います。プロセス ノードをステータスから分離するには、プロセス テーブルを作成し、主要なプロセス ステージをレコードとして定義します。プロセスの上位段階と下位段階を含みます。この表を使用して、このワークフローの流れを特定します。これにより、拡張性も向上します。
質問者が拡張するのが難しいと言ったのは、状態が多すぎて、状態間の遷移がネットワーク状になっていて、状態を変更するコードがプログラム全体に広がるため、直接的な結果が発生するという意味ですか?状態間の遷移の関係を明確にしたり、状態のロジックを変更したりすると、プログラム全体に変更が生じ、高いリスクが生じます。
つまり、状態間の遷移が非常に複雑な場合は、状態間の遷移関係を構成によって解決でき、状態間の遷移関係をステート マシン モデルに統合できると思います。 。
詳細については、以前に抽象化したステート マシン モデルを参照してください: State Machine