CQRSとイベントソーシングの違い
CQRS（コマンドクエリ責任分離）とイベントソーシングの違いは何ですか？
イベントソーシングはCQRSの一種だと思います。それぞれを区別するものと、イベントソーシングが他のタイプのCQRSと異なる点は何ですか？
ありがとう、
CQRS
CQRSはGregYoungによって導入されました。 2010年の彼の説明
CQRSは、以前は1つしかなかった2つのオブジェクトを作成するだけです。分離は、メソッドがコマンドであるかクエリであるかに基づいて行われます（Meyerがコマンドとクエリの分離で使用するのと同じ定義です。コマンドは状態を変更するメソッドであり、クエリは値を返すメソッドです）。
通常、これは、目的に合うように、各オブジェクトがデータの異なる表現を使用することを意味します。ここでの一般的な言葉は、「書き込みモデル」と「読み取りモデル」を指すことです。通常、最初に書き込みモデルに変更が加えられ、読み取りモデルに非同期で伝播されます。
たまたま、数字の「2」には魔法はありません。 2つと同じくらい簡単に3つの異なる表現を持つことができます。
ここでの主な利点は、読み取りユースケースと書き込みユースケースのデータ構造を個別に調整できることです。
イベントソーシング
非破壊の方法で状態を記録するためのパターンを調達するイベント。状態の各変化は ログに追加されます です。変更は非破壊的であるため、ライフサイクルの任意の時点でオブジェクトの状態に関するクエリに回答する機能を保持します。
イベントを使用すると、（差分を格納するだけの場合と比較して）変更のセマンティックな意図を保持しながら、（各変更後の状態の完全な表現を格納する場合と比較して）ストレージスペースをより効率的に使用できます。
グレッグは、この方法でイベントソーシングについて説明しました
現在の状態を一連のイベントとして保存し、その一連のイベントを再生してシステム内で状態を再構築します
CQRS +イベントソーシング
ログは、概念的なデータ構造として、クエリのサポートに特に効率的ではないため、これらの手法は頻繁にペアになります。通常は、読み取りに適した他の表現（書き込みよりもはるかに頻繁になる可能性が高い）にログを凝縮する必要があります。
したがって、CQRSパターンでは、通常、永続性モデルとしてログを使用し、そのログからオブジェクトのクエリに適した表現を作成し、クエリをすばやくサポートできるようにそれらの表現をキャッシュします（表現で使用される妥協点を受け入れます）。クエリは、利用可能な最新の情報を常に反映するとは限りません）。
簡単な実世界の例を見てみましょう。
CQRS：読み取りクエリにはcache/redis/elasticsearchを使用し、書き込みクエリにはdatabase/mysql/mongoを使用します。これがまさにCQRSです。読み取りロジックと書き込みロジックを分離するのがCQRSです。
イベントソーシング：使用するすべてのPub/Subパターンは、イベントソーシングに分類されます。ここでは、メッセージを1つのイベントとしてキュー（kafka/RabbitMQ）に公開し、サブスクライバーはこれらのキューをサブスクライブすることでメッセージを消費します。
CQRS +イベントソース：上記の例のみを取り上げます。書き込みモデル（データベース/ mysql/mongo）が更新された場合、読み取りモデル（cache/redis/elasticsearch）をどのように更新する必要がありますか？
ここでイベントソースを使用できます。データベースが更新されるたびに、1つのイベント（変更を含む）が作成され、そのイベントがキューにプッシュされます。これで、Reader Model（elasticsearch）はこれらのキューをサブスクライブし、その状態に加えてイベントを適用します。したがって、読み取りモデルと書き込みモデル全体で同じ状態を維持しています。
CQRS：
CQRSは、Command Query ResponsibilitySegregationの略です。グレッグヤングによって紹介されました。すべてのメソッドは、アクションを実行するコマンドまたはデータを返すクエリのいずれかである必要があります。コマンドはデータを返すことができず、クエリはデータを変更できません。各モデルは特定のコンテキストに合わせて最適化でき、概念的な整合性も保持します。
イベントソーシング：
CQRSにはイベントソーシングは必要ありません。イベントソーシングとCQRSを組み合わせることができます。この種の組み合わせは、新しいタイプのCQRSにつながる可能性があります。これには、アプリケーションによって行われた状態の変化を、不変のシーケンスまたはイベントのログとしてモデル化することが含まれます。システムへのログインとイベントロギングについて考えるかもしれませんが、正直なところ、イベントロギングはイベントソーシングではありません。イベントソーシングは、現在の状態を履歴から取得するように強制します。履歴から現在のシステムについて推論できない場合は、イベントソーシングを行っていません。確かに、イベントはビジネス上の事実です。
ドメイン駆動設計では、イベントはユビキタス言語に従う必要があり、システム内のすべてのイベントは過去形であり、過去形で名前が付けられている必要があります。イベントは独立しています。つまり、イベントには自分自身を説明するのに十分なデータが必要です。
イベントソーシングの人気が高まっています。トラブルシューティングが容易になり、パフォーマンス特性が向上するためです。書き込みと読み取りは個別にスケーリングできます。 GRASPイベントサワーが疎結合アプリケーションアーキテクチャを有効にすることを指します。また、同じイベントを処理する必要があるが、異なるマテリアライズドビューを作成する必要があるアプリケーションを将来追加することもできます。