cqrs - イベント ソーシングなしの CQRS - 欠点は何ですか?

Question

イベント ソーシングの利点の一部が失われる以外に、イベント ソーシング部分なしで既存のアーキテクチャを CQRS に適応させることの欠点はありますか?

私は大規模なアプリケーションに取り組んでおり、開発者は今後数か月で既存のアーキテクチャをコマンドとクエリに分離できるようになるはずですが、この段階でイベント ソーシングも追加するように依頼することは、リソースの調達から大きな問題になるでしょう。視点。イベント ソーシングを含めないことは冒涜にあたるのでしょうか?

Answer 1

イベントソーシングはオプションであり、ほとんどの場合、導入が早すぎると役立つ以上に複雑になります。特に、レガシーアーキテクチャから移行する場合、およびチームがCQRSの経験がない場合はさらに多くなります。

ESに起因する利点のほとんどは、イベントを単純なイベントログに保存することで取得できます。状態ベースの永続性を削除する必要はありません（ただし、ある時点で論理的な次のステップになるため、長期的には削除する可能性があります）。

私の推奨事項：シンプルさが鍵です。特にこのような劇的なパラダイムシフトを導入する場合は、一度に1ステップずつ実行してください。単純なCQRSから始めて、あなた（およびあなたのチーム）が新しい概念に慣れてきたら、イベントログを導入します。次に、必要に応じて、永続性をイベントソーシングに変更し、DBAを起動します;-)

Answer 2

イベント ソーシング パターンには根本的な問題があります。コードの変更により、イベント ストア内のイベントがアプリケーション内のイベント ハンドラーと互換性がなくなる可能性があります。

そうは言っても、新しい機能を追加してイベント ハンドラーを変更するときは常に、下位互換性について考える必要があります。コードの異なるバージョンによって作成された異なるステージで、コードが常に同じイベントを処理できることを確認する必要があります。

アプリケーションがより複雑になると、下位互換性を維持するのが非常に困難になることがわかります。

Answer 3

イベント ソーシングは、人々が CQRS を恐れる理由だと思います。それには理由があります。それは自然なことではありません。現実世界で何かを操作するとき、このオブジェクトに関するすべての履歴を取得する必要はありません。

「<strong>イベント ソーシングは、CQRS とは完全に直交する概念です」( source ) - 技術的には、ES を使用しない場合、CQRS 機能から失うものは何もありません。

イベントソーシングが、メッセージの重複/欠落、メッセージの並べ替え、データの衝突などの「メッセージング」関連の問題を解決するための唯一の基盤と見なされる理由がわかりません。イベントを使用しない場合はそうではありません他の方法でそのような問題を解決するためのカプセル化された手段を作成することはできません。

ここで読むことができる別のデータ編成原則を使用して CQRS のメッセージングを実装する別の方法をどのように見るか。

データを変更イベントの構成としてではなく、責任あるユーザーによって署名された不変部分の構成として扱う「署名済みドキュメント」アプローチを提案します。メッセージ フローとデータ ストレージを実装するソリューションは他にもたくさんあると思います。また、どちらを使用するかを選択する際には、ビジネス モデルを考慮する必要があります。

Answer 4

私の意見では、CQRS でイベント ソーシングを使用しないことは大きな間違いです。

まず、クエリ モデルとコマンド モデルの同期で問題が発生することはほぼ確実です。イベント ストアを使用すると、クエリ側が同期しなくなった場合に、イベントを再生して修正するだけで済みます。とにかくそれが理論です！

しかし、イベント ソーシングを使用すると、すべてのエンティティ トランザクションの完全な履歴を保存することもできます。これは、実装後に新しいクエリとビューを作成することを決定できることを意味します。これらは、多くの場合、非イベント ソース CQRS では不可能なビューです。Greg Young が、ショッピング カートに追加されてから削除されたアイテムを照会する例を挙げているのを聞いたことがあります。イベント ソーシングを使用すると、これが可能になります。カートの最終状態のみを保存するため、ES がないと不可能です。