イベント ソーシングは、イベント履歴/監査証跡、完全で一貫性のあるビューの再生成など、多くのことに対するボーナスとして売り込まれています。素晴らしいですね。私はファンです。しかし、これらは読み取り側の実装の詳細であり、別のサブスクライバーとしてイベント ストアを完全に読み取り側に移動することで同じことを実現できます。
ここにいくつかの考えがあります：
- ビュー/デノーマライザー自体は、イベント ストアを気にしません。ドメインからのイベントを処理するだけです。
- イベント ストアを読み取り側に移動しても、イベント履歴/監査が得られます
- イベント ストアから引き続きビューを再生成できます。ただし、書き込みモデルのリークである必要はありません。彼に模範市民権を与えてください！
これは、書き込み側にとどめておくための1つの技術的議論のようです。これはhttp://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/の Greg Young によるものです。
ただし、現在の状態のスナップショットを保存しているものを使用すると、いくつかの問題が発生します。最大の問題は、データに 2 つのモデルを導入したという事実に関係しています。イベント モデルと現在の状態を表すモデルがあります。
これについて私が興味深いと思うのは、「スナップショット」という用語です。これは、最近ではイベント ソーシングでも際立った用語になりました。書き込み側にイベント ストアを導入すると、集計の読み込みにいくらかのオーバーヘッドが追加されます。オーバーヘッドがどのくらいかについて議論することはできますが、スナップショットとスナップショット以降のすべてのイベントから集計をロードするという概念があるため、これは認識または予想される問題であるようです。これで、再び 2 つのモデルができました。それだけでなく、私が目にしたスナップショットの提案は、パフォーマンスを維持するためにデータ ストア全体をバックグラウンド プロセスで処理して、インフラストラクチャ リークとして実装することを目的としています。
そして、スナップショットが作成された後、スナップショットの前のイベントは、読み取り側を再構築することを除いて、書き込みの観点からは 100% 役に立たなくなります! それは間違っているようです。
もう 1 つのパフォーマンス関連のトピック: ファイル ストレージ。エンティティに大きなバイナリ ファイルを添付する必要がある場合があります。概念的には、これらはエンティティに関連付けられることもありますが、エンティティである場合もあります。これらをイベント ストアに入れるということは、エンティティをロードするたびにそのデータを物理的にロードする必要があることを意味します。それは十分に悪いことですが、これらの数または数百が大きな集合体になることを想像してみてください。これに対する私が見たすべての答えは、基本的に弾丸をかみ、URIをファイルに渡すことです。これは警察の妨害であり、分散システムを弱体化させます。
あとはメンテナンスです。ビューの再構築には、イベント ストアを含むプロセスが必要です。したがって、これまでに作成したすべてのビュー メンテナンス タスクは、書き込みモデルをイベント ストアを使用するようにさらにバインドします。
読み取りモデルと書き込みモデルのユース ケースが根本的に互換性がないというのが、CQRS の要点ではないでしょうか。では、柔軟性とパフォーマンスを犠牲にして、それらを再び結合して、なぜ書き込み側に読み取りモデルを配置する必要があるのでしょうか。なぜ時間を費やすのですか？
全体として、私は混乱しています。私が座っているすべての点で、イベント ストアはモデルの詳細を読むのに適しています。イベント ストアを維持することの多くの利点は引き続き得られますが、書き込み側の永続性を過度に抽象化することはなく、柔軟性とパフォーマンスが低下する可能性があります。また、漏れやすい抽象化とメンテナンス タスクによって、読み取り/書き込み側を結合することもありません。
それで、誰かがそれを書き込み側にしておくための1つ以上の説得力のある理由を私に説明してもらえますか? または、メンテナンス/レポートの問題として、読み取り側に移動しないのはなぜですか? 繰り返しますが、私はストアの有用性を疑っていません。どこに行くべきか:)