イベントソーシングなしのCQRS-欠点は何ですか？
イベントソーシングの利点のいくつかを見逃していることに加えて、イベントソーシングの部分なしで既存のアーキテクチャをCQRSに適応させることに他の欠点はありますか？
私は大規模なアプリケーションに取り組んでおり、開発者は今後数か月で既存のアーキテクチャをコマンドとクエリに分離できるようになるはずですが、この段階でイベントソーシングも追加するように依頼することは、リソースからの大きな問題になります。視点。イベントソーシングを含めないことで犠牲を払っていますか？
イベントソーシングはオプションであり、ほとんどの場合、導入が早すぎると役立つ以上に複雑になります。特に、レガシーアーキテクチャから移行する場合、およびチームがCQRSの経験がない場合はさらに多くなります。
ESに起因する利点のほとんどは、イベントを単純なイベントログに保存することで取得できます。状態ベースの永続性を削除する必要はありません（ただし、ある時点で論理的な次のステップになるため、長期的にはおそらく削除するでしょう）。
私の推奨事項：シンプルさが鍵です。特にこのような劇的なパラダイムシフトを導入する場合は、一度に1ステップずつ実行してください。単純なCQRSから始めて、あなた（およびあなたのチーム）が新しい概念に慣れてきたら、イベントログを導入します。次に、必要に応じて、永続性をイベントソーシングに変更し、DBAを起動します;-)
私はデニスに完全に同意します。ESはCQRSの前提条件ではありません。実際、CQRS自体は実装が非常に簡単で、設計を本当に単純化する可能性があります。
あなたはそれへのスムーズな紹介を見つけることができます ここ
次に、CQRS自体がテーブルにもたらすメリットは何ですか？
- すべてのクエリの懸念を吸い出すことにより、ドメインオブジェクトを簡素化します
- コードのスケーリングが可能になり、クエリが分離され、簡単に調整できるようになります
- 製品設計を繰り返すときに、全体としてより大きな構造（エンティティ、集計、モジュールなど）を処理する代わりに、個々のコマンド/クエリを追加/削除/変更できます。
- コマンドとクエリは、ドメインの専門家と話すためのよく知られた語彙を生成します。他のアーキテクチャパターン（パイプやフィルター、アクターなど）は、プログラマー以外の人が理解するのが難しい用語や概念を使用しています。
- ORMの使用を制限します（使用する場合）。クエリに使用しようとすると、ORMは不当な複雑さをもたらすと思います。抽象化はリークが多く、重いので、調整しようとすると悪夢になります：）ORMを使用するのはコマンド側では作業がはるかに簡単になります。クエリにはプレーンな古いSQLが最適です。おそらく、単純なライブラリを使用して結果セットをDTOに変換するのが最も必要です。
CQRSが設計にどのように役立つかについての詳細 ここ
また、 CQRSの目に見えない利点 も忘れないでください
それでも疑問がある場合は、 これを読んでください
現在、中程度の複雑さのプロジェクトにCQRSを使用しており、非常に適していることがわかりました。 custom bootstrap code を使用して開始し、次に Axon Framework を使用してインフラストラクチャコンポーネントの一部を提供するようになりました。
もっと具体的なことを知りたい場合は、PM私までお気軽に。
イベントソーシングパターンには根本的な問題があります。つまり、コードの変更により、イベントストア内のイベントがアプリケーション内のイベントハンドラーと互換性がなくなる可能性があります。
そうは言っても、新しい機能を追加してイベントハンドラーを変更するときは常に、下位互換性について考える必要があります。コードの異なるバージョンによって作成された異なるステージで、コードが常に同じイベントを処理できることを確認する必要があります。
アプリケーションがより複雑になると、下位互換性を持たせるのが非常に苦痛になります。
イベントソーシングは、人々にCQRSを恐れさせるものだと思います。そしてそれは理由です。それは自然なことではありません-現実の世界で何かと対話するとき、このオブジェクトに関する全体の履歴を取得する必要はありません。
「イベントソーシングはCQRSと完全に直交する概念です」（ ソース ）-技術的には、ESを使用しない場合は緩みますCQRS機能からは何もありません。
イベントソーシングが、メッセージの重複/欠落、メッセージの並べ替え、データの衝突など、いくつかの「メッセージング」関連の問題を解決するための唯一の基盤と見なされる理由がわかりません。イベントを使用しない場合はそうではありません。カプセル化された手段を作成できないソーシングは、そのような問題を他の方法で解決することを意味します。
別のデータ編成の原則を使用してCQRSのメッセージングを実装する別の方法をどのように見るか ここ を読むことができます。
データを変更イベントの構成としてではなく、責任のあるユーザーによって署名された不変部分の構成として扱う「署名付きドキュメント」アプローチを提案します。メッセージフローとデータストレージを実装するための他の多くのソリューションがあると確信しています。また、使用するビジネスモデルを選択する際には、ビジネスモデルを考慮する必要があります。
私の意見では、CQRSでイベントソーシングを使用しないことで大きな間違いを犯しています。
まず、クエリモデルとコマンドモデルの同期に問題が発生することはほぼ間違いありません。イベントストアを使用すると、クエリ側が同期しなくなった場合に、イベントを再生して修正する必要があります。それはとにかく理論です！
ただし、イベントソーシングを使用すると、すべてのエンティティトランザクションの完全な履歴を保存することもできます。これは、実装後に新しいクエリとビューを作成することを決定できることを意味します。これらは、イベントソース以外のCQRSでは不可能なビューであることがよくあります。 Greg Youngが、ショッピングカートに追加されてから削除されたアイテムをクエリする例を示していると聞きました。イベントソーシングを使用すると、これが可能になります。 ESがないと、カートの最終状態のみを保存するため、それは不可能です。
私の意見では、CQRSパターンベースのフレームワークとして最適なのはJimmy BogardによるMediatRです。アプリケーション開発の最初にイベントソーシングが必要ない場合は、MediatRが正しい選択です。これがリポジトリです- https://github.com/jbogard/MediatR