最初の部分を読んでください。
イベントソーシング実装の機能
技術的な観点から、イベントソーシングでは、イベントのログ記録とログからの読み取りの実装のみが必要です。
最も単純なケースでは、ファイルをイベントストレージとして使用できます。このストレージでは、各行に個別のイベントが記録されるか、各イベントが個別のファイルに保存されるときに複数のファイルが記録されます。ただし、原則として、並列処理とスケーラビリティが要求される大規模なシステムでは、より信頼性の高いストレージ方法が使用されます。
イベントログは、メッセージブローカー（メッセージ指向のミドルウェア）およびイベントストリーム処理システムと組み合わせて使用される非常に一般的なパターンです。イベントログとして使用されるメッセージブローカーは、必要に応じてメッセージ履歴全体を保存できます。
リレーショナルモデルとドキュメンタリーモデルは、通常、エンティティモデリングに重点を置いています。このようなモデルでは、現在の状態は1つ以上の行またはドキュメントを読み取ることで簡単に取得できます。イベントソーシングとリレーショナルモデルは相互に排他的ではないことに注意してください。イベントソーシングシステムには、多くの場合、両方が含まれます。イベントソーシングとの主な違いは、エンティティストアが生データとして扱われなくなったことです。イベントログの再処理により、交換または再構築できます。
より複雑なイベントソーシングシステムでは、イベントログ全体を経時的に処理して現在の状態を取得するとスケーリングが停止する可能性があるため、効率的な読み取り要求のために派生状態ストアが存在する必要があります。リレーショナルデータベースとドキュメントデータベースはどちらも、イベントログとしても、派生エンティティのリポジトリとしても使用できます。これにより、現在の状態をすばやく取得できます。実際、この懸念の分離はCQRS（Command Query Responsibility Segregation）です。すべてのリクエストは派生ストアにルーティングされるため、書き込み操作とは関係なく最適化できます。
技術的な部分以外にも、注意が必要な点があります。
潜在的なイベントソーシングの問題
イベントソーシングには利点がありますが、欠点もあります。
最大の課題は通常、開発者の考え方にあります。開発者は、従来のCRUDアプリケーションやエンティティストアを超えて移動する必要があります。イベントがメインコンセプトになるはずです。
イベントソーシングでは、イベントのモデリングに多くの労力が費やされます。イベントがログに書き込まれた後、変更されていないと見なす必要があります。そうしないと、履歴と状態が破損または破損する可能性があります。イベントログは生データです。つまり、特定の時点でシステムの完全な状態を取得するために必要なすべての情報が含まれていることを確認するために、細心の注意を払う必要があります。また、システム（およびそれが表すビジネス）が時間の経過とともに変化するにつれて、イベントが再解釈される可能性があることにも留意する必要があります。また、データ検証を正しく処理することで、誤った疑わしいイベントを忘れないでください。
単純なドメインモデルの場合、この考え方の変更は非常に簡単ですが、より複雑なドメインモデルの場合、問題になる可能性があります（特に、エンティティ間の依存関係や関係が多い場合）。特定の時点でデータを提供しない外部システムと統合するのは難しい場合があります。
イベントログパターンは自然に水平方向にスケーリングされるため、イベントソーシングは大規模なシステムでうまく機能します。たとえば、あるエンティティのイベントログは、別のエンティティのイベントログと物理的に存在する必要はありません。ただし、このスケーリングの容易さは、非同期処理と最終的には一貫性のあるデータという形で追加の問題を引き起こします。状態を変更するためのコマンドは任意のノードに送信できます。その後、システムは対応するエンティティを担当するノードを判別し、これらのノードにコマンドを送信してコマンドを処理し、生成されたイベントをイベントログが保存されている他のノードに複製する必要があります。そして、このプロセスの完了後にのみ、新しいイベントがシステム状態の一部として利用可能になります。したがって、イベントソーシングでは、実際にはコマンド処理をステータス要求、つまりCQRSとは別にする必要があります。
したがって、イベントソーシングシステムは、コマンドを発行してからイベントログの成功に関する通知を受信するまでの時間間隔を考慮する必要があります。この時点でユーザーに表示されるシステム状態は「間違っている」可能性があります。というか、少し時代遅れです。この要因の影響を減らすために、ユーザーインターフェースや他のコンポーネントを設計する際にそれを考慮する必要があります。また、コマンドが失敗したり、実行中にキャンセルされたり、データが更新されたときに1つのイベントが新しいイベントに置き換えられたりする状況を適切に処理する必要があります。
イベントが時間の経過とともに蓄積し、それらを処理する必要がある場合、別の問題が発生します。処理後にそれらを書き留めるのは1つのことであり、履歴全体を処理するのは別のことです。この機能がないと、イベントログの値は完全に失われます。これは、災害復旧や、データを更新するためにすべてのイベントを再処理する必要がある派生ストアを移行する場合に特に当てはまります。イベントの数が多いシステムの場合、ログ全体を再処理すると、許容可能な回復時間を超える可能性があります。システムの定期的なスナップショットは、後で正常な状態から回復を開始できるように、ここで役立ちます。
イベントの構造も考慮する必要があります。イベントの構造は時間とともに変化する可能性があります。フィールドのセットは変更される場合があります。古いイベントを現在のビジネスロジックで処理する必要がある場合があります。また、拡張可能なイベントスキームの存在は、将来、必要に応じて、新しいイベントと古いイベントを区別するのに役立ちます。定期的なスナップショットは、イベントの構造の主要な変更を分離するのにも役立ちます。
結論
イベントソーシングは、メリットのある強力なアプローチです。その1つは、将来のシステムの拡張を容易にすることです。イベントログにはすべてのイベントが保存されるため、外部システムで使用できます。新しいイベントハンドラーを追加することで、統合するのはかなり簡単です。
ただし、他の主要なアーキテクチャ上の決定と同様に、状況に合わせて機能するように注意する必要があります。ドメインの複雑さ、データの一貫性と可用性の要件、および長期的に保存されるデータの量とスケーラビリティの増加に関連する制約は、これらすべてを考慮する必要があります（これは完全なリストではありません）。そのようなシステムをそのライフサイクル全体を通して開発および維持する開発者に注意を払うことも同様に重要です。
そして最後に、ソフトウェアエンジニアリングの最も重要な原則を忘れないでください-すべてを可能な限りシンプルに保つように努めてください（KISSの原則）。
