CQRSアプローチで読み取りモデルを構築するためにElasticSearchを使用している人はいますか? そのようなソリューションに関連するいくつかの質問があります:
ドメイン イベントの正式なリポジトリが配置されている場所は、実装の詳細です。たとえば、シリアル化されたバージョンを S3 や CouchDB、またはその他の数のストレージ実装に保存できます。始めたばかりの場合は、リレーショナル データベースが最も簡単です。
通常、ユーザーは、各メッセージの背後にあるビジネスの意図を理解するイベント ハンドラーを使用し、ビューのニーズに適した読み取りモデル構造にメッセージを適切に非正規化できます。
ビュー モデルが破損したり、ビュー モデル ハンドラーにバグがある可能性がある場合は、バグを修正した後に実行する簡単な手順がいくつかあります。
ドメインから到着するイベント フローを一時的にキューに入れます。これらは、ドメインが作業を行っているときにパブリッシュされる典型的なメッセージです。これらのメッセージは引き続き必要ですが、まだではありません。これは、メッセージ バスをオフにするか、キューイング インフラストラクチャを使用している場合は接続しないことで実現できます。
イベント ストレージからすべてのイベントを読み取ります。各イベントが受信されると (これは単純な DB クエリを介して実行できます)、適切なメッセージ ハンドラーを介して各メッセージを実行します。処理されたすべてのメッセージの最後の 10,000 個 (またはそれくらい) の識別子を追跡していることを確認してください。
キューに再接続して、通常どおり処理を開始します。メッセージの識別子が表示された場合は、メッセージをドロップします。それ以外の場合は、通常どおり処理してください。
識別子を追跡する理由は、イベント ストアからすべてのイベントを取得しているにもかかわらず、同じメッセージがメッセージ キューを介して受信されるという競合状態を回避するためです。
関連性が高いが、すべてのメッセージ識別子を追跡することを含む別の手法は、http: //blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.htmlにあります。