私は基本的にCRUDアプリケーション（作成、読み取り、更新、削除）であるWebアプリケーションに取り組んできました。最近、私は「承認ワークフロー」と呼んでいるものに取り組み始めました。基本的に、リクエストはマテリアルに対して生成され、承認のためにマネージャーに送信されます。要求された内容に応じて、さまざまな人が要求を承認するか、変更のために要求者に送り返す必要があります。承認者は、何が承認されたかを追跡する必要があり、要求者は、要求のステータスを確認する必要があります。
「CRUD」開発者として、私はこれを設計する方法に頭を悩ませることに苦労しています。どのデータベーステーブルが必要ですか？リクエストの状態を追跡するにはどうすればよいですか？リクエストに対して発生したアクションをユーザーに通知するにはどうすればよいですか？
彼らのデザインパターンは私をこれに役立てることができますか？コードでステートマシンを描画する必要がありますか？
これは一般的なプログラミングの質問だと思いますが、何か違いがあれば、MySQLでDjangoを使用しています。
これには設計パターンがあります。多分彼らは少し助けるでしょう：
http://en.wikipedia.org/wiki/Workflow_patterns
ワークフローは単純な CRUD アプリよりも状態駆動型です。そのため、ステート マシンのパターンを読むことも役に立ちます。正しい軌道に乗っているようですね。
データ モデリングに関しては、状態のテーブルへの外部キーである状態フィールドを使用して、すべての「承認」のテーブルを作成できます。
通知に関しては、承認の状態を変更するときにアプリが行う必要があることです。特定の状態の変更について誰/何を通知する必要があるかを確認するために、他の場所を検索する必要があります (したがって、何を追跡する必要があります)エンティティは、どの状態変化について通知を受けます)。
承認 == 状態変更
State Change == 変更されたものへの更新 && 何かが変更されたことを記録するためのログの作成。
それでおしまい。
興味深いルールは、「誰が更新を許可されているか?」、「どの州の変更が法的な更新であるか?」、「どの州が行き止まりであるか?」です。
あなたは有限オートマトンを構築しています。状態はオブジェクトの属性です。状態を更新することで、「ワークフローを通じて」何かをプッシュします。
多くの人が言っているように、それを承認することは新しい状態に移行することです.
私が遭遇した考慮すべきことは、ユーザーが頻繁に同じ「状態」にあるものを持ちたいと思っているだけでなく、その状態の別のステップまたはタスクにあることを記録したいということです。たとえば、ユーザーは「要求済み」と「処理中」を区別したい場合があります。承認の観点からは、要求されたものと処理中のものは両方とも未承認 (オープン) です。何かが承認済みから未承認 (オープン) に戻った場合、彼らはそれを「レビューが必要」と呼ぶかもしれませんが、それでも承認されていません。
したがって、次のようなものが必要になる場合があります。
要求: 開く
処理中 : 開く
レビューが必要 : オープン
承認済み : 承認済み
時間が経つにつれて、ユーザーはおそらくより多くの「モード」または「タスク」を必要とするでしょう。これらのそれぞれの状態を作成すると、あなたや彼らが本当に望んでいたよりもはるかに複雑になる可能性があります. 状態との多対 1 の関係で、ユーザーが必要な数の「モード」または「タスク」を持つことができるようにすると、ユーザーの観点からはより単純になりますが、ユーザーの観点からはより正確になります。
これは非常に頻繁に発生したため、汎用ルーティング システムを作成しました。あなたがやっていることはおそらくやり過ぎですが、アイデアを掘り起こすことは大歓迎です。チェーン (順次承認) またはスター (ブロードキャスト) のいずれかを使用して、任意のコンテンツを任意のユーザーにルーティングし、承認するための最小限の投票を許可します。これは、スキーマの自動生成された ERD です。
基本的に、1 つ以上のルーティング スキーム リストを含むルーティング スキームがあります。各リストはチェーンまたはスターのいずれかであり、スキーム全体はチェーンまたはスターとして開始できます。各リストとスキーム全体は、独自の votes_to_approve を持つことができます。これは、1 つのスターと 1 つのチェーンの 2 つのリストを持つ「スター」タイプのスキームを持つことができることを意味します。スキーム全体で votes_to_approve を 1 に設定できるため、いずれかのリストが承認すると、ワークフロー全体が承認されます。チェーン リストにはメンバーの数に等しい votes_to_approve を含めることができるため、次のメンバーが投票する前に各メンバーが承認する必要があり、最初に承認しなかったメンバーがそのリストを削除します。スター リストでは、votes_to_approve を 1 に設定して、リスト内の誰でもワークフロー全体を即座に承認できるようにすることができます。
これらのスキームは無期限に保存され、一度設定すると再利用できます。スキームを実装するために、Routing テーブルのエントリは、scheme_id、ルーティングされるもの、および承認と非承認のテキストなどの詳細で作成されます。「routing_」テーブルは、実装されたスキームの状態を格納します。
アプリケーション間のイベント システムを使用して、ルートの状態が変化したときに電子メールを送信したり、他のアプリケーションに通知したりします。
私は現在、同様のプロジェクトに参加しています(異なるプラットフォーム/DB)。
CRUDできるレコードの種類に関して、さまざまなレベルのユーザー権限を持つDBアプリがあります。ほとんどの場合、許可される操作をコードで制御します。
ただし、多くの構成要素については、構成要素の「ステータス コード」があり、その構成要素に対して誰が何を実行できるか、およびどのステータス コードに移動できるかを (コードで) 定義します。