イベントソーシング（イベントソーシング、イベントロギング、イベント生成）は、アプリケーションの状態に加えられたすべての変更が発生した順序で保存される強力なアーキテクチャパターンです。これらのレコードは、現在の状態を取得するためのソースと、アプリケーションの存続期間中にアプリケーションで発生したことの監査証跡の両方として機能します。イベントソーシングは、分散型データの変更と読み取りを容易にします。このアーキテクチャは拡張性が高く、すでにイベント処理を行っているシステムや、そのようなアーキテクチャに移行したいシステムに適しています。
イベントソーシングとは
ドメインエキスパートは通常、システムをエンティティのコレクションとして説明します。エンティティは、さまざまなビジネスプロセス内で入力データを処理した結果としてエンティティの変更を反映する状態とイベント（イベント）を格納するためのコンテナです。多くの場合、イベントは、ユーザーからのコマンド、バックグラウンドプロセス、または外部システムとの統合によってトリガーされます。
基本的に、イベントソーシングは、システムの変更に関連するイベントに焦点を合わせています。
多くの建築パターンでは、エンティティを主要な概念と見なしています。これらのテンプレートは、それらを保存する方法、それらにアクセスする方法、およびそれらを変更する方法を説明しています。この建築スタイルの中で、イベントはしばしば「横向き」です。それらはエンティティの変更の結果です。
通常、これらのアーキテクチャは、リレーショナルデータベースやドキュメントストアなどのエンティティストアに基づいています。イベントはそのようなアーキテクチャに存在する可能性がありますが、本質的には主要な概念ではなく、関連付けられているエンティティから分離したり、ビジネスロジックのレイヤーの背後に隠したりすることができます。
イベントソーシングは、イベントの実装に焦点を当てることにより、このアプローチを逆転させます。つまり、イベントを永続化する方法と、エンティティの状態を取得するためにイベントを使用する方法です。この場合、データベースには、システムの存続期間中に発生したすべてのイベントの順次ログが含まれます。
以下は、イベントストアとエンティティストアの比較です（以下で詳しく説明します）。
イベントを主要なアーキテクチャコンセプトとして使用するイベントソーシングは、システムに対する顧客の見方をより適切に反映するドメインモデリングパラダイムでもあります。イベントとイベントログに重点を置いてシステムを設計すると、次の利点があります。
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
銀行口座の簡単な例を見てみましょう。銀行口座を代表する事業体があります。簡単にするために、アカウント番号やその他の方法でアカウントを特定せずに、アカウントを1つだけ作成します。アカウントは現在の資金残高を維持します。
アカウントでは、預金（預金）と引き出し（引き出し）の2つのコマンド（コマンド）を使用できます。コマンドは、預け入れまたは引き出しの金額を示します。また、要求された金額が現在のアカウント残高以下の場合にのみ引き出しコマンドを処理できることを確認するビジネスルールを定義します。
このアプローチでは、2つのイベントを区別できます（イベント）-「アカウント貸方記入」および「口座借方記入」。これらのイベントには、預け入れまたは引き出した金額に関する情報が含まれています。これは、正または負の合計を持つ単一のイベントに簡略化できますが、この例では、それらを分割します。
次の図は、データモデルを示しています。
イベントは「過去の緊張」であることに注意してください。これらは、作成時にシステムで何が起こったかを示し、コマンドが正常に処理された場合にのみ保存されます。このアプローチでは、コマンドとイベントを混同しないように注意する必要があります。特にそれらが互いにミラーリングしている場合。
コマンドのシーケンスは次のようになります
。1.deposit{amount：100} -deposit 100
2. withdraw {amount：80} --withdraw 80
3. withdraw {amount：50}
--withdraw 50イベントソーシングの最も単純な実装には、イベントログが必要です。これは単なる一連のイベントです。上記のコマンドを処理すると、そのようなログが得られます。
要求された金額が使用可能な残高を超えているため、3番目のコマンドを実行できません。
現在のバランスを取得するには、システムはイベントを発生順に処理または「生成」する必要があります。この例では、次のようになります。
- 銀行口座{現在の残高：0}（開始状態）
銀行口座{現在の残高：0}（開始状態） - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
現在の残高は、現在までのすべてのイベントの処理を通じて計算されます。各イベントには暗黙のタイムスタンプがあるため、必要な期間のすべてのイベントを処理することで、いつでもアカウントの状態を計算できます。
これは、イベントソーシングの完全な（些細なことではありますが）例です。実際のシステムでは、この例を拡張する必要がある可能性があります。
イベントがどのように発生したかを識別できるようにコマンドのシーケンスを保存する必要がある場合があります。また、エラーをさらに処理し、成功との完全な履歴を維持するために、完了できなかったコマンドを記録する別のエラーイベントログを作成する必要があります。失敗したチーム。
時間の経過とともに、コマンドの数が増えると、現在のアカウントの残高を維持する必要がある場合があります。これにより、引き出しコマンドを受信したときに、イベントの完全なリストを処理して、コマンドを実行できるかどうかを判断する必要がなくなります（つまり、アカウントに十分な資金があるかどうか）。これは派生ストアの例であり、基本的にエンティティストアと同じです。
以下は、すべてのコマンドを処理した後、エンティティストアがこの例を検索する方法です。
明らかに、本格的なイベントストアと比較すると、これは非常に原始的な例です。これが、多くの開発者がエンティティストアのみを使用する理由の1つです。この場合、現在のアカウント残高はすぐに利用可能であり、すべての履歴イベントを処理する必要はありません。
ただし、イベントソーシングはエンティティストアを除外しません。多くの場合、エンティティストアはイベントソーシングプロジェクトにも存在します。
最初の部分の終わり。
