私は、おそらく 10 台のマシンの小規模ビジネス向けの新しいソリューションを設計しています。ビジネスは非常に小さく、24 時間 365 日稼働するサーバー自体さえ持っていません。そのため、NServiceBus/RavenDB を選択することは、信頼性の高いキュー操作のための当然の選択のように思えました。クライアントの観点からは、(多かれ少なかれ) 美化されたリポジトリにはなりません。
これまでの設計では、1 つのサーバーと複数のクライアントを使用しています。初日、コマンドが処理され、オブジェクト X、Y、または Z の状態が変化したことを示すイベントが送信されるため、クライアントはローカルの RavenDB キャッシュを更新して、信頼できる即時のクエリを実行できます。しかし、解決できない問題は、企業が将来新しいマシンを搭載することを決定したときに何が起こるかということです。この新しいマシンは 0 日目に起動しなかったため、他のすべてのマシンと状態を同期するためのスクリーンショットがありません。
確かに、サーバーがダウンした場合に備えて、サーバーは典型的な SQL データベースを介して「スクリーンショット」を保存していますが、(ほぼ純粋な) CQRS ソリューションでこれらのスクリーンショットを新しいクライアントに適切に伝えるにはどうすればよいですか?
クライアントは、開始する巨大なスクリーンショットを要求するコマンドを送信する必要がありますか?
新しいクライアントの初日に、別のクライアントからキャッシュを複製する必要がありますか?
クライアントは、サーバーの SQL データベースに直接接続して、必要に応じて独自のスクリーンショットを同化できるようにする必要がありますか?
イベントソーシングに似たものを実現しようとするときに、クライアントがサーバーの永続ストアに接続できるようにすることは、汚れている/不純であると見なされますか? (この場合、イベントの監査テーブルを保存するのではなく、クライアントに依存して、イベント ソーシングに影響するキャッシュにイベントを投影します。)