以下は、ワークフロー システムでのユース ケースです。
作業指示書がシステムに入力されます。作業指示には、作業指示を完了する前にさまざまなワークフロー状態を通過するターゲットがあります。
ターゲット車両の作業指示書がシステムに入ったとします-この作業指示書のワークフローには2つのタスクが含まれます
a) 洗車
b）車両を検査する
車両の洗浄ワークフロー タスクによって、車両の属性が「未洗浄」から「洗浄済み」に変更されたとします。そして、「車両を検査する」というワークフロー タスクは、車両の属性を「未検査」から「検査済み」に変更します。
ユーザーが作業指示書データをプルしている場合、ユーザーには常に最新の車両データが表示されます (この例では、両方のワークフロー タスクが完了していると仮定すると、ユーザーには「洗浄済み」と「検査完了」という値が表示されます。ただし、ユーザーがワークフロー タスク洗浄車両データのみをプルすると、ユーザー -> ユーザー"washed" と表示されます - 2 番目のタスクは完了していますが、ワークフロー タスク 1 はそれが変更されたことのみを認識します。ワークフロー タスク 2 のデータを取得すると、"washed" と "inspection done" の両方が表示されます。
これには、データのミルストーン (監査証跡) が含まれます。1 つのアプローチは、下の画像に示すとおりです。ワークフロー タスクがデータを変更すると、バージョン番号 modified_ts が更新され、そのバージョン番号が独自のデータ行に保持されます (以下に示すように、JOIN テーブルを介して)。基本的に、これはワークフロー タスク データの履歴レコードへの参照を維持することに他なりません。したがって、ワークフロー タスク データをプルするときに、どの履歴レコードをプルバックするかを認識します。parent_idその他の注意事項、下図のノイズは無視してください。この質問には関係ありません。
イベントソーシングも別の代替設計になると考えていますが、イベントソーシング（または他の同様のソリューション）を販売ソリューション全体として適用したくはありませんが、この特定のユースケースにのみ適用します（監査証跡がある3つほどのテーブルのみに影響します）重要）。CQRS/イベント ソーシングが部分的な解決策として適しているかどうかを評価しようとしています (ここでも、履歴/監査証跡データを保存する必要がある 3 ～ 4 個のテーブルに限定されます)、または ES/CQRS は過剰になりますか? 他の考えはありますか？
PSこれはScalaとは関係ありませんが、Scalaは私たちが使用しているプラットフォームであるため、タグ付けして、役立つ言語固有のソリューションがあるかどうかを確認します. Akka の永続性を介した ES/CQRS がオプションであるかどうかを調べるために、Akka にタグを付けます。Postgresql は db です - DB トリガーは私が探しているソリューションではありません。