Functional Programming in C# まとめ 10章

9章のまとめは、こちら

Chapter 10. Event sourcing: a functional approach to persistence

この章では以下の内容を説明する。

• 永続化されたデータについて関数型的に考える
• イベントソーシングの考え方と実装
• イベントソーシングシステムのアーキテクチャ

10.1. Thinking functionall about data storage

今日、多くのサーバアプリケーションはステートレスだ。状態は複雑の主要な発生源であるため、この方法は効果的であることが証明されている。

しかし、DBの値が更新や削除されるとしたら、グローバルでミュータブルな状態の大きな塊を共有してるようなものだ。

RDBには最新の状態のみを保存する傾向がある。が、過去の情報が知りたい場合、大変である。よくある方法としては、過去の状態の履歴を保存しておく方法がある。しかし、これは、何が変わったのかを突き止めるのが困難なので、非効率である。

イベントソーシングでは、イベントのデータを保存する。状態は2次的なものだ。実際に、エンティティの状態は、イベント履歴の関数である。

10.2. Event sourcing basics

イベントソーシングの基本的な考え方

• イベント:何が起こったか？の詳細情報
• 状態:ある時点のエンティティのスナップショット
• 状態遷移:状態とイベントを取り、新しい状態を返す関数

イベントは、何が起こったかを示す必要最小限のデータで構成されるため、イベントごとにデータの形式が異なる。これを永続化するには様々な選択肢がある

• イベントに特化したDBを使う。Event Storeのような
• ドキュメントデータベースを使う。Redis、MongoDB、その他のような。これらのストレージシステムは保存するデータの構造を仮定していない。
• 伝統的なRDB

RDBの場合は、ヘッダをつけて、データは本体は、JSONにする。

イベントを永続化する方針の場合、状態は何に使うか？

• コマンドの実行の仕方を決定するためにスナップショット
• ユーザに表示するためにスナップショット

ある状態とあるイベントがあれば、次の状態を計算できる。これを状態遷移という。

state -> event -> state

ただし、一番最初は状態がないので、特殊な形式になる。

event -> state

※個人的には、状態の引数にユニット与えればよい気がしますが、それか、Option型にしてMatchするとか。

10.3. Architecture of an event-sourced syteom

イベントソーシングを採用した場合、CQRSにできる、という議論。

Tuples in C# 7

名前付きタプルができるようになったが、その場合タプルの値が変更可能となる。

10.4. Comparing different approaches to immutable storage

状態を永続化しない方法として、アサーションベースの方法もあるとのこと。ただし、アサーションベースの方法を選択するためには、実質的に1つのサードパーティ製品を利用するしか方法がない。

イベントソーシングやアサーションベースの方法をアプリケーションに適用するかどうかは、要件しだい。