Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ざっくりCQRS/Event Sourcingを解説する
Search
かとじゅん
October 27, 2020
Programming
18
9.4k
ざっくりCQRS/Event Sourcingを解説する
かとじゅん
October 27, 2020
Tweet
Share
More Decks by かとじゅん
See All by かとじゅん
メッセージ駆動が可能にする結合の最適化
j5ik2o
10
2.9k
曖昧なプロンプトでも正しいコードが書ける理由
j5ik2o
0
410
AIコーディングエージェントの現実と設計品質の重要性
j5ik2o
0
110
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
16
7.6k
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
8
1.5k
メッセージとイベントを中核に置いたシステム設計の有用性について
j5ik2o
12
4.1k
私のキャリアの旅路: 技術をきっかけに変化を楽しむ
j5ik2o
3
970
いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える
j5ik2o
5
3k
社内のメンバーに「関数型プログラミングの学習・教育」についていろいろ聞いてみた
j5ik2o
2
2.2k
Other Decks in Programming
See All in Programming
UIデザインに役立つ 2025年の最新CSS / The Latest CSS for UI Design 2025
clockmaker
18
7.5k
20251212 AI 時代的 Legacy Code 營救術 2025 WebConf
mouson
0
180
宅宅自以為的浪漫:跟 AI 一起為自己辦的研討會寫一個售票系統
eddie
0
510
Rubyで鍛える仕組み化プロヂュース力
muryoimpl
0
130
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
7.3k
dotfiles 式年遷宮 令和最新版
masawada
1
780
リリース時」テストから「デイリー実行」へ!開発マネージャが取り組んだ、レガシー自動テストのモダン化戦略
goataka
0
130
ZOZOにおけるAI活用の現在 ~モバイルアプリ開発でのAI活用状況と事例~
zozotech
PRO
9
5.7k
AIエンジニアリングのご紹介 / Introduction to AI Engineering
rkaga
8
2.8k
これだけで丸わかり!LangChain v1.0 アップデートまとめ
os1ma
6
1.9k
Canon EOS R50 V と R5 Mark II 購入でみえてきた最近のデジイチ VR180 事情、そして VR180 静止画に活路を見出すまで
karad
0
120
実は歴史的なアップデートだと思う AWS Interconnect - multicloud
maroon1st
0
180
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
Speed Design
sergeychernyshev
33
1.4k
Navigating Team Friction
lara
191
16k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
100
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Unsuck your backbone
ammeep
671
58k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3k
Transcript
ざっくり CQRS/Event Sourcing を解説する かとじゅん(@j5ik2o) 設計ナイト2020
DDDに関係はしますが、 ドメインモデルそのものではなく 分散システムの設計パターンについて 話します
誰? • Chatworkで仕事してます。現在は分散システムの設計・実装を担当しています。 • 2016年からk8s+Akka+Kafka+HBaseを用いた、CQRS/Event Sourcingシステム を運用しています。 • 現在もAkka-Clusterへのマイグレーションを計画中
DDDによるクエリサイドのペインについて これらのペインを飲み込めるの であれば、CQRSを採用する 必要はない
C/Qの独立した最適化ができないか? それがCQRSだ
CQRSとは • Command and Query Responsibility Segregation=コマンド・クエリ責務分離 ◦ (2010年 Greg
Young氏) • コマンドとクエリをスタックごと隔離すること。単なるモデルの分離ではない。Event Sourcingとセットで採用されることが多い。 • Greg Young氏の論文でも隔離のための境界があると明示されている • コマンドはDDDのドメインモデルを内包することを想定している。というか、DDDの ために考えられたパターン。CQRSである=DDDを採用していることになる。 • モデルだけ分離して、隔離の境界がないものはCQRSと呼んではいけない(個人の 解釈) とはいえ、CQRSですべてが解決されるわけではない
CQRS/Event Sourcingのイメージ スナップショット ストレージ 必要に応じてVOを使ってリード モデルを構築する
イベントをどう使うのか • 理解を促すための擬似コー ド。CRUDよりレイテンシが悪 化する例なので真似しないよ うに…。 • エンティティのライフサイクル をリクエストスコープから分離 する必要がある。そのために
Actorを使う
「えっ、複雑やんけっ…」 一旦落ち着こう
なぜC/Qをわけるのか • そもそもCとQで要件が異なるので、混ぜないで隔離するほうが望ましい。 • ただし、データ形式がクライアント要求に合わせる必要がなければC/Qを分けなくて もよい。そういう案件に巡り会えたことがないが…。 コマンド クエリ 一貫性/可用性 一貫性重視。最新の書き込みが反映され
るなければならない。トランザクション整合 性(強い整合性)を使う 可用性重視。つまりちょっと古いデータ見 えてもよい。結果整合性 (弱い整合性)を使 う データ形式 正規化されたデータを保存する (集約単位 ≒概念単位) 非正規化されたデータ形式取得する (クラ イアント要求に合わせる ) スケーラビリティ 全体のリクエストに対して少ない比率。必 ずしもスケーラビリティは重要ではない 全体のかなりのリクエスト比率を占めるた め、スケーラビリティが必要
CQRSの利点と欠点 • 利点 ◦ コマンドとクエリに分離されており独立しているため、耐障害性を確保しやす く、デプロイサイクルも別にできる ◦ コマンドとクエリを必要に応じて個別に最適化できる。別々にスケールさせるこ とができる •
欠点 ◦ コストがかかる。目的ごとにスタックを分離するので、構成要素が多くなる。 ◦ CQRSは従来と比べると複雑と揶揄されることが多いが、従来モデルではC/Q が混在することの複雑があったが、CQRSではある意味シンプルになってい る。が全体の構成要素は複雑なる。 ▪ つまり、単体のオブジェクトとしてはシンプルになるが、ネットワークとして は複雑になるということ
• CQRSでは、ドメインオブジェクトはドメインロジックを実行するためのシンプルなモデ ルとなる。ただし、全体の構造は複雑になる CQRSでモデルがどう変わるか メッセージの本文を持 つのはつらい メッセージの本文を保 持しなくてよい
非Event SourcingでのCQRSはいろいろ難しい • ドメインオブジェクトが計算する値 はそもそも永続化されていない。 その値がリードモデルで必要な 場合、DBトリガで更新を通知して SQLでリードモデルを構築できな い •
リードモデル更新プロセスを採用 する場合、DBとは別途キューを 必要とする。結局Eventに頼るこ とになる。 • できるだけダブルコミットを避けて、障害でノードが消失しても再開できるようにイベント は永続化される必要がある。Event Sourcingではイベントを真のデータソースにす る。 スケーラビリティの観点でポーリ ングが難しいので、 pub/subを利 用する
CQRS/ES対応分散システムフレームワーク • Akka https://akka.io (Scala, Java) • Akka.NET https://getakka.net/ ,
https://akkatecture.net/ (.NET) • proto.actor https://proto.actor/ (Golang, .NET, Java/Kotlin) ◦ リアクティブシステムが作れそうなのは Golangのみ 11k starts, 2010~ 3.3k starts, 2016~ 3.7k starts, 2014~
完全にC/Qを分けるのは無理… クエリサイドのペインも 許容できないんだけど…
境界を引かない=非CQRSにする(現実解) • クエリでは一切リポジトリを利用しない。ただしVOに依存することがある • リポジトリはドメインロジックのために使う(findById, store, deleteのみ)
FYI: Scala/Akkaを学ぶための薄い本を売ってます • Scala 2.13とAkka 2.6(Akka-Typed)で解説しています。 10冊売れた 29冊売れた