現在、CQRS とイベント ソーシング アーキテクチャを評価しています。この種の設計を使用することでメンテナンスにどのような影響があるかを理解しようとしています。答えを見つけるのに苦労している 2 つの質問は次のとおりです。
1) アプリケーションがしばらく稼働した後、ReadModel データベースの ViewModel に追加フィールドを追加するという新しい要件が発生した場合はどうなりますか? たとえば、CustomerList ViewModel では、以前は必要なかった Customer Zip Code が必要です。この場合、ViewModel データベースに追加の列を簡単に追加できますが、これはどのように設定されるのでしょうか? 私が知る限り、唯一の方法は、読み取りデータベースをクリアし、すべてのイベントを最初から再生して ReadModel データベースを再構築することです。しかし、アプリケーションが数か月、または数年 (そうなることを願っています) 稼働していた場合はどうでしょうか。ZIP コード列にデータを追加するためだけに、再生するイベントが何百万にもなる可能性があります。
技術的な理由により、ReadModel データベースが同期しなくなった場合や、新しい ReadModel データベースを追加したい場合にも、同じ懸念があります。アプリケーションが古く、使用頻度が高いほど、最新の ReadModel を取得するのが難しくなり、コストも高くなるようです。それとも、どこかにコツが欠けているのでしょうか。ReadModel スナップショットのようなものでしょうか。
2) 数百万のイベントをすべて再生して読み取りデータベースを再構築した後、一部のデータが予想と一致しない場合 (つまり、間違っているように見える場合) はどうなりますか。おそらく、イベントの保存または非正規化ルーチンのどこかにバグがあり、これが原因であると考えられます (コーディングで頼りになるものがあるとすれば、それはバグであると思われます)。これをデバッグするにはどうすればよいでしょうか。不可能な作業のように思えます。あるいは、ここでも、私が何か見逃しているのかもしれません。
このようなシステムをしばらく運用している方から、メンテナンスとアップグレードのパスがどのように機能したかを聞きたいです。
ご意見をお寄せいただきありがとうございます。
ベストアンサー1
CQRS でイベント ソーシングを使用する利点は、すでに述べたように、読み取りモデルを破棄して最初から再構築できることです。何らかの理由で、イベント数が一定数を超えると、長い時間がかかると考える人がいます。読み取りモデルにリレーショナル データベースを使用している場合 (おそらくそうでしょう)、トランザクションを開いて、ハンドラーを通じてすべてのイベントを読み取り、トランザクションをコミットするのは簡単です。実際にディスクにアクセスするのは、トランザクションがコミットされたときだけです。他のすべてはメモリ内で実行されるため、非常に高速です。実際、システムが数分で数百万のイベントを処理しても驚きません。
読み取りモデルを最初から再構築すると、イベントを読み取りモデルに非正規化する通常の方法とまったく同じように表示されるはずです。そうでない場合は、読み取りモデルの非正規化コードにバグがあります。ここでの素晴らしい点は、メッセージ ハンドラーの観点からは、通常/運用シナリオと読み取りモデルの再構築シナリオで、イベントが受信されて読み取りモデルに非正規化されることに違いがないことです。
バグが発生した場合は、実稼働イベントをローカル ワークステーションにストリーミング/コピーし、ハンドラーにブレークポイントを設定して、読み取りモデル処理コードを通じてそれらのイベントを実行することで、簡単にデバッグできます。