回答:
イベントソーシングの主な質問は、「記録簿は何ですか」です。
レコードブックがイベントストリームの場合、問題はありません。レコード帳が「エンティティモデル」の場合、問題はあちこちで発生し始めます。これの一部は、「エンティティモデルを失った場合、イベントストリームから再構築できますか」と言えることです。あなたがこの質問に肯定的であるならば、あなたのイベントログはあなたの記録の本です。
イベントソーシングを使用するほとんどの人が読み取りモデルを使用することを覚えておくことも重要です。このモデルは、データのクエリに使用されます。ただし、これは3nfエンティティモデルよりも1nfモデルのように見えます。それらは、書き込みを許可する必要があるかどうかを判別するために、アグリゲートの状態を取得するためにイベントを再生するだけです。
システムアーキテクチャを変更する場合も、イベントソーシングのメリットを最大限に活用できます。少なくとも私の意見では、DDDと組み合わせたCQRSスタイルのアーキテクチャに移行すると、イベントソーシングの真のメリットがもたらされます。
大規模なシステムで適切に動作するイベントストアを構築することは、実に簡単な作業ではありません。すべてのデータを再生すると、実際にはコストがかかる可能性があり、再生する必要のあるデータの量に大きく依存します。しかし、これを手助けするかもしれないテクニックがあり、それらの1つはスナップショットの概念です。再生はある時点からのみ行われます。イベントストアがシステムにもたらす利点は非常に貴重です。システムで発生したすべてを再生可能にすると、あらゆる瞬間のすべてのデータが素晴らしいことになります。分析、バグの再現、統計について考えてください。
素晴らしいイベントショップはたくさんありますが、最後のストアは昨日イベントストアがリリースされたばかりで、本当に良いもののようです。
従来のデータベースを維持して、システムのクエリ部分で、要求されたデータを使用してDTOを構築できます。このデータベースは、アプリケーションとクライアントのクエリニーズを考慮して整理および最適化できます。
イベントソーシングと組み合わされたCQRSアーキテクチャがどのように実際にどのように見えるか、およびその利点についての詳細な記事を書きました。CQRS、ドメインイベント、DDDレビューで確認できます。
すべてのエンティティを含むDBを引き続き使用できますか？または、アプリケーションが起動されるたびにイベントを再生して、メモリ内の各エンティティの最新バージョンを取得する必要がありますか？
答えは、アプリケーションの要件によって異なります。私はそれが両方の方法で行われるのを見てきました。
小規模な会計事務所向けの非常に成功したソフトウェアパッケージの1つは、起動時に毎回CQRSログを読み取ります。生のデータ量は比較的少なかったため、遅いコンピュータでも起動時間は1分未満でした。彼らは、実践が普及する前の10年以上にわたってCQRSを行ってきました。大規模なシステムで発生する問題に遭遇することなくクライアントデータを何度もアップグレードできることに気づいたとき、彼らは何か良いことをしていることを知っていました。
データ量が多いシステムや、クエリ側を実装するためにRDBMS機能に依存するシステムでは、イベントソースデータの「現在のビュー」用のデータベースがあります（そのようなビューを複数持つこともできます）。このアプローチの利点は、使い慣れたテクノロジを使用してクエリ側を構築できることです。