オブジェクト履歴 (イベント ストア) の調査を必要とするいくつかのドメイン ルールを実装する必要がある状況があるとします。たとえば、CurrentStatus プロパティを持つ Order オブジェクトがあり、Order.CurrentStatus の変更履歴を調べる必要があるとします。
ほとんどの場合、この知識をドメインに移し、ステータス レコードのコレクションを含む Order.StatusHistory プロパティを導入する必要があり、イベント ストアにクエリを実行するべきではないと答えるでしょう。そして、私はあなたに同意します。
私が疑問に思うのは、Event Store の必要性です。
ビジネス上の意味を持つイベント ストア イベント (ドメイン値) を書き込みます。UserMovedMouse イベントは記録しません (ほとんどの場合)。また、OrderStatusChanged イベントと同様に、ドメイン ロジックのある時点で EventStore からのほとんどのイベントが必要になる可能性が高く、イベントのコレクションを持つ EventHistory プロパティを持つドメイン オブジェクトになります。
単一の書き込み専用イベント ストアと複数の読み取り専用クエリ ストアがある場合、CQRS などのパターンの個別のイベント ストアに値が表示されるため、ある程度のスケーラビリティが得られます。しかし、そのようなことをコードに導入する必要性は、私にとっても疑問です。すべての適切なデータベースは、単一の書き込みサーバー、複数の読み取りサーバーのスケーラビリティ (マスター/スレーブ レプリケーション) をサポートしています。なぜ、ソース コード レベルでそのようなことを導入する必要があるのでしょうか。Web サービスとメッセージ バスを忘れて、ソケットの周りに独自のラッパーを作成してください。
私は、Eric Evans によって説明された「古い学校」の DDD に大きな敬意を払っています。また、新しい波の DDD+SQRC+EventSourcing パターンの集合体には、新鮮で優れたアイデアがいくつか見られます。しかし、CQRS の主なアイデアは、私にとって大きな疑問です。何か不足していますか？