CQRS・ESでぶち当たった悩み3選

CQRS・ESでぶち当たった悩み3選 by event-store-adapter-swift 田中 陽一朗

プロフィール 名前 田中陽一朗 @lemo-nade-room 会社 Nextbeat 24卒入社 保育士バンク！コネクト （労務・シフト作成に特化した保育ICT） Scala, Angular 学校 奈良高専

CQRS・ESで コード量は増えたし複雑化した

目的 CQRS・ESの開発速度が落ちる コスパの悪いやり方を避けてもらう

目次 1. 従来設計とEvent Sourcingの集約の違い 2. 短命なデータに対するEvent Sourcing 3. event-store-adapterとの付き合い方

従来設計とEvent Sourcingの集約の違い 従来設計の集約とESの集約は リードモデルではない点で異なる 従来設計 リードモデル ≒ 集約 Event Sourcing リードモデル ≠ 集約

従来設計とEvent Sourcingの集約の違い 集約を状態ごとに分けることができる

従来設計とEvent Sourcingの集約の違い イベント・集約の生成をより簡単に

従来設計とEvent Sourcingの集約の違い 書き込みのテストの辛さは ほとんど集約の初期化の辛さになっている テスト工程 1. 集約初期化 2. コマンド実行 3. 集約を検証

従来設計とEvent Sourcingの集約の違い replayして集約を生成し、 コマンド後のイベントを検証 テスト工程 1. イベントから集約をreplay 2. コマンド実行 3. イベントを検証

短命なデータに対するEvent Sourcing 短命なデータに対するESのコスパの悪さ 例 Passkey認証 S3等へのファイルアップロード セッション系

短命なデータに対するEvent Sourcing Passkey認証を作ろうとしてイベントが大量発生

短命なデータに対するEvent Sourcing 一瞬だけチャレンジトークンを保存する必要

短命なデータに対するEvent Sourcing 一瞬だけ発生するデータはESで扱わない DynamoDBやRedis、RDB等に格納するように し、イベントとしては保存しない

短命なデータに対するEvent Sourcing 短命なデータを扱うサービスを切り出して 1つのコマンドにする

event-store-adapterとの付き合い方 event-store-adapterとは 以下の4つのインターフェイスの定義 Aggregate Event AggregateId EventStore

event-store-adapterとの付き合い方 event-store-adapterとは 以下の4つのインターフェイスの定義のみ Aggregate →使用者が準拠 Event →使用者が準拠 AggregateId→使用者が準拠 EventStore →ライブラリが提供

event-store-adapterとの付き合い方 event-store-adapterとは ライブラリが提供するEventStoreAdapter EventStoreAdapterForMemory EventStoreDynamoDB

event-store-adapterとの付き合い方 event-store-adapterに直接依存しないと ほぼライブラリと同じコードを書くことになった 依存しない難点 ライブラリ使用前提で不明なプロパティを集約やイベ ントに生やす必要がある テスト時にEventStoreForMemoryを車輪の再発明しな ければならない

event-store-adapterとの付き合い方 最終的の結論が依存するになった ほぼインターフェイスのみの定義でシンプルな ライブラリのため、小さいなら直接依存 依存したくないなら完全コピペがいい

event-store-adapterとの付き合い方 イベントソーシング系ライブラリに 依存しないことは難易度が高い 慣れていないならば、最初から依存しないこと を考えずに、直接依存した方が早い

まとめ Event Sourcing最高なのでもっと慣れて プロダクト初期のコスパを良くしたい イベントソーシングは集約設計を変えることで実装量は 増えるがテストをシンプルにできる 短命なデータにはイベントソーシングする価値があるか を確認し、イベントソーシングにこだわりすぎない event-store-adapterには依存した方がコスパがいい