Event Sourcing

1. 削除された 情報を 戻せる

1.1. 緊急時に 強い

1.1.1. ユーザーの 操作ミス

1.1.2. 悪意ある ユーザーによる 全情報削除

2. 整合性を保持しやすい

2.1. アプリケーションデータベースはソースから常に新規作成される

2.1.1. テーブル間の整合性を保持できる

2.1.2. 整合性が破れても次回の更新で戻る

3. 分散処理しやすい

3.1. Event Sourceや中間ファイルを転送すると別マシン上で続きを処理できる

3.2. 各アプリケーションデータベースを別マシン上に置ける

4. Event Source は テキストであるべき

4.1. 比較, 検索, 加工しやすい

5. 簿記は Event Sourcing

5.1. お金に 関する 出来事 (イベント) を すべて 記載する

5.1.1. 残高変更には 理由が 記載される

5.1.2. 残高を いきなり 修正したり しない

5.2. 期ごとに 集計し, 繰り越しする

5.2.1. 期首を キャッシュする

5.2.2. 期中は 期首と イベントから 現在の 状態を 作成する

6. ユーザーからの 入力を 再現しやすい

6.1. 不具合時の 動作検証が やりやすい

7. 別マップ: Persistence 層, DB に 関する アイデア

8. ID は どこで 付けるべき?

8.1. イベントに 付ける?

8.2. 処理 ロジックで 付ける?

8.3. キャッシュ DB で 付ける?

8.4. もし LMAX のような ライブオブジェクトシステムなら ID を 管理する オブジェクトが 居るはず

8.4.1. The LMAX Architecture