私が所有するサイトには、うまく機能している単純な CQRS アーキテクチャがあります。イベントは発行され、さまざまなサブスクライバーによって取得されます。そのうちの 1 つが [RavenDb で] レポート データベースの同期を維持します。
たとえば、レポート データベースが破損または紛失したとします。イベント ソーシングを使用すると、イベントを再生してレポート データベースを再構築できますが、[現在] イベント ソーシングは使用していません。リレーショナル ストアへの単純な nHibernate 永続化機能があります。解決策は、基本的にリレーショナル ストアに基づいてすべてのイベントを送信する「再生成」タイプのスクリプトを作成することでしょうか (たとえば、PersonCreatedEvent に続いて 30xPersonLikedBlogPostEvent など)。基本的にイベント ソースと同じことを行いますが、イベントはリレーショナル モデルから推測されます。
保守性と DR は明らかに重要であるため、ここでは困惑しています。
イベントを保存しないと、再生できません。リレーショナル ストアを使用して "Created" イベントだけを生成すると、この "regeneration" からメリットを得ることができなくなります。
サーバーに送信されたすべてのコマンドを (たとえば、ログに) 保存した場合、最初のコマンドから最後のコマンドまですべてのコマンドをバスに送信でき、すべてのクエリ側を再現できます。それがコマンドソーシングです。コマンド ソーシングを使用すると、準備ができたらいつでも簡単にイベント ソーシングに進むことができます。
これを実現するために、本格的なイベントソーシングソリューションを実装する必要はありません。すべてのイベントをイベントログに保存するだけで、必要に応じてそれらを取得して再生できます。
これには簡単で迅速な解決策はないと思います。これは、データをリレーショナルからイベントソースに移行する場合に実際に行う必要があることです。あなたが言ったように、あなたができる唯一のことは、各エンティティがもっともらしい順序でイベントをスクリプト化することです（つまり、CreatedEvent、次に他の状態変更イベント）。ただし、これらのイベントをキャプチャすると、後で再実行できるように保存します。