アクターシステムに頼らずEvent Sourcingする方法について

イベントソーシングやCQRSパターンの実装では、しばしばアクターモデル（Akka/Pekkoなど）が用いられますが、本セッションではそれに頼らない実装方法を解説します。Amazon DynamoDBを使ったイベントストアの実装方法を中心に、実際のコードを交えながら説明します。

Transcript

1. アクターシステムに頼らず Event Sourcing する 方法について かとじゅん(@j5ik2o) Press Space for next page
2. 自己紹介 Kubell 社( 旧Chatwork 社) テックリード。 ウェブ業界に転身後、Scala やDDD を採用した開発に従事。現在は次 期アーキテクチャの設計に携わる → 次あります 執筆 プロダクトデザインやソフトウェア設計の本を書いてるけどいつ 出るか… レビュー 改訂版 良いコード／悪いコードで学ぶ設計入門 WEB+DB PRESS Vol.132 - 特集1 オブジェクト指向神話からの脱 却 ドメイン駆動設計入門 Akka 実践バイブル エリックエヴァンスのドメイン駆動設計 twitter: j5ik2o github: j5ik2o
3. CQRS+Event Sourcing は難しい？ それなりに難しいとは思いますが まず注目するところはコマンド側。 モジュール化の技法の一つとしてみると理解しやすい
4. 今日の話題 データベースもわける必要あるの？ C とQ をつなげるストリーム処理をどうやって実現する？ コマンド側にアクターモデルが必要なんでしょ？ ← 今日はここの話
5. FYI: アクターモデルといえば アクターモデルは、メッセージをやりとりするための軽量プロセスモデルで、以下の実装がよく知られている Akka/Pekko Proto.Actor 特に Proto.Actor はとても参考になる。Akka は内部実装が複雑になりすぎている… 。今からやる人は Proto.Actor の実装を学ぶとよいです。Proto.Actor の影響を受けた実装は以下。 PHP での実装: https://github.com/ytake/phluxor Rust での実装: https://github.com/j5ik2o/nexus-actor-rs
6. CQRS+Event Sourcing が想定するシステム構成
7. 想定のシステム構成 集約はドメインモデルの集合体 コマンドを受け付け、状態遷移する（状態機 械） 更新のための状態は保持できるが閲覧はできな い コマンドに成功するとイベントを送出する 集約そのものではなくイベントが永続化される 集約という単位でオブジェクトグラフを手にで きる DB とは直接関係ないのでインピーダンスミス マッチも解決しない( 関係があるのはイベント の方) 集約をアクターという軽量プロセスで実現するのが一般的。今日はその集約をクラスベースで実現する方法に ついて考える。
8. アクターモデルを使わなくても実現は可能 ただし、イベントストアをどのように実現するかという課題がある。 ヒントは以下。AWS さんのドキュメント。 Amazon DynamoDB を使った CQRS イベントストアの構築 AWS データベースブログの記事 「Amazon DynamoDB による CQRS イベントストアの構築」 を勝手に読み解 く なぜDynamoDB なのだろうか？→ CDC が比較的容易にできるNoSQL だから
9. AWS さんの提案方式
10. 【AWS 方式】 テーブル構成 Aggregate （集約） ：ビジネスロジックの実装をカプセル化するCQRS パターン Event ：何かが起こったことを示すイベント Snapshot ：特定の時系列ポイントまでに起こったイベントから導出された状態を示すスナップショット。 スナップショットを使うとランタイムで全てのイベントの履歴を保持したりロードしたりする必要がなくな ります。
11. 【AWS 方式】 Event テーブル 最初からイベントをこのテーブルに保存しない このテーブルからはCDC （変更データキャプチャ）できない。Aggregate からやることになる…
12. 【AWS 方式】 Aggregate テーブル version は楽観的ロックのために使う last_events は未処理イベントの列。
13. 【AWS 方式】 Snapshot テーブル
14. どのように動作するのか
15. 【AWS 方式】 集約を読み込むロジック Aggregate テーブルを読む last_events があればEvent テーブルに書き込む。CQS 違反?? その後Snapshot テーブルを読み、Event を読む last_events はEvent テーブルに追記するだけではなくAggregate からlast_events を消さないといけない。Event へのPutItem と同時に行わないと安全とは言えないのでは？？結局トランザクションが必要では？？
16. 【AWS 方式】 集約を書き込むロジック 興味があればご自分で調べてみてください。本題ではないので割愛します
17. というわけでシンプルな方法【KJ 方式】を提案します
18. 【KJ 】j5ik2o/event-store-adaptor-* DynamoDB をイベントストア化するためのライブラリを作った。 AWS さんとは違って最初からトランザクシ ョンを使い、CQS の原則に従う https://github.com/j5ik2o/event-store-adapter Go,Rust,Java,Scala,Kotlin サンプル実装 https://github.com/j5ik2o/cqrs-es-example 実績 Black Cat Carnival
19. 【KJ 】DynamoDB テーブル仕様
20. 【KJ 】Journal テーブルはSnapshot,Journal の二つ pkey パーティションキー ${ 集約種別名}-${hash( 集約ID) % 論理シャードサイズ} skey ソートキー ${ 集約種別名}-${ 集約ID の値部分}-${ シーケンス番号} aid: 集約ID seq_nr: シーケンス番号 payload: イベント本体 occurred_at: 発生日時 ` ` ` `
21. 【KJ 】Snapshot pkey パーティションキー ${ 集約種別名}-${hash( 集約ID) % 論理シャードサイズ} skey ソートキー ${ 集約種別名}-${ 集約ID の値部分}-${ シーケンス番号} 。最新のスナップショットはシーケンス番号=0 aid: 集約ID seq_nr: シーケンス番号 ttl: 削除のためのTTL version: 楽観的ロック用のバージョン ` ` ` `
22. 【KJ 】イベントストアの設計を考える 必要なインターフェイスは4 つだけ
23. 【KJ 】DynamoDB の細かい話をすると伝わらないと 思うので、ここではインメモリ操作で説明する
24. 【KJ 】最初のイベントとスナップショットの書き込み Event はSnapshot と同じトランザクションで書き込まれる 更新にはSnapshot#version を使って楽観的ロック（条件付き書き込み）を行う 更新に成功したらversion をインクリメントする
25. 【KJ 】イベントのみの書き込み Event はSnapshot と同じトランザクション。ただしSnapshot のversion 以外のカラムは更新しない 更新にはSnapshot#version を使って楽観的ロック（条件付き書き込み）を行う 更新に成功したらversion をインクリメントする
26. 【KJ 】最新スナップショットの取得 集約ID からスナップショットデータを取得する
27. 【KJ 】差分イベント集合の取得 集約ID とシーケンス番号から差分イベント集合を取得する。イベント集合は大きさの上限を決めることがで きる
28. 【KJ 】リポジトリの実装例 findById 内部で集約をリプレイする。
29. 【KJ 】ユーザアカウントのリプレイ
30. 【KJ 】GroupChat#postMessage ドメインモデルは閲覧要件をカバーしない。あくまで更新動作に注力 インピーダンスミスマッチを解消しない。オブジェクトモデルだけで考える。 データモデルはイベントとリードモデルに任せる
31. まとめ コマンド側のドメインモデルは オブジェクトモデルだけで考えることができる 閲覧のことを考えないのでモデルが小さくなる クエリはクエリの事情に合わせて考える コマンドとクエリの間はどうすんの？？？ → また今度お会いするときにお話しましょう！
32. おしまい