イベントソーシングでのCRUDの "テーブル"への対応

Question

私はESの旅を開始し、伝統的なサポートテーブルをイベントログに保存する必要があるかどうか、これらの表には典型的にCRUDページがあります。言い換えれば、同じアプリケーションで2つのアプローチ、つまりサポートテーブル用とトランザクションデータ用の2つのアプローチを持つのは一般的でしょうか。

サポートテーブルは、会計アプリケーションの「アカウント」、ERPアプリケーションの「製品タイプ」または実際の「製品」テーブル（ERPアプリケーションを作成していない - これはタイプの例です）のようになります。テーブルについて話している）。

私たちがイベントログにCRUDタイプのデータを保存する場合は、我々が持っているかもしれないイベントは：

• は
• が（削除としてマークだけでしょう）
• ProductDeletedをProductUpdated ProductCreated

次に、（ProductUpdatedイベントで）何が変更されたのかを調べ、変更を保存して再生して、製品の最新のイメージを取得しようとしますか？

ほとんどの場合、私はCRUDテーブル（伝統的なものか、イベントログに保存するもの）にどのようなアプローチをとっていますか？追加情報は素晴らしいでしょう！

Answer 1

ProductCreatedなどのイベントやその他のデータストアなど、イベントログを使用して純粋に開始するとします。アプリケーションが起動するたびに、すべてのイベントをログに記録して現在の状態を構築する必要があります。今

、アプリ（たとえばproductsテーブル）の現在の状態を保存するために、伝統的なSQLテーブルを作成するとしその状態（たとえばlast_event表）に到達するために処理された最後のイベントのID 。アプリが起動するたびに、のIDがIDよりも高いイベントを再生し、新しい状態を構築するイベントを処理する必要があります。

あなたのアプリは、これらの2つの状態を同期させた状態で維持するように注意する必要があります。並行処理が必要な場合は、SQLテーブルでのみアトミック操作を実行するように注意する必要がありますが、それはトランザクションではかなり簡単です。

Answer 2

サポートテーブルは、イベントストリームの読み取りモデル/投影です。一般的に、必要な場合に備えてサポートモデルを作成することはありません。 read-modelは、UIのどこかで使用する場合にのみ作成します。

とにかく、Event sourcingの背後にある重要な利点の1つは、クエリにjoinを使用する必要がないということです。つまり、必要なすべてのデータ（完全な非正規化）を含むread-modelごとにtableを作成します。あなたはそのテーブルをクエリに対して超最適化した状態に保ちます。