Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ざっくりCQRS/Event Sourcingを解説する
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
かとじゅん
October 27, 2020
Programming
9.7k
18
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ざっくりCQRS/Event Sourcingを解説する
かとじゅん
October 27, 2020
More Decks by かとじゅん
See All by かとじゅん
TAKTでAI駆動開発の品質を設計する
j5ik2o
9
2.3k
終盤で崩壊させないAI駆動開発
j5ik2o
5
3.4k
CQRS/ESになぜアクターモデルが必要なのか
j5ik2o
0
2.4k
メッセージ駆動が可能にする結合の最適化
j5ik2o
11
7.3k
曖昧なプロンプトでも正しいコードが書ける理由
j5ik2o
0
550
AIコーディングエージェントの現実と設計品質の重要性
j5ik2o
0
180
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
17
8.5k
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
8
1.8k
メッセージとイベントを中核に置いたシステム設計の有用性について
j5ik2o
12
4.5k
Other Decks in Programming
See All in Programming
初心者DevRelとして参加者だった私が、DevRel Talks!#2に登壇するまでにしてきたこと
sokohirai
0
360
typoなんかねぇよ
raspython3
0
690
App Storeの外へ──日本のiOSサイドローディング入門 for iOSDC Japan 2026
yuukiw00w
0
170
テストを司るデーモンに会いに行く 〜隔離した仮想マシンでテストを通すまで〜
h1d3mun3
1
140
フロントエンドUIフレームワークのこれまでとこれから
ssssota
5
2.4k
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
450
【高い買い物LT会】初任給で話題の国産フィジカルAIを買った話
akagami
PRO
0
140
[GoCon2026] When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go
takehaya
6
1.8k
Building an Out-of-Order CPU
latte72
1
750
型解析で実現する Go の言語内 DSL / Conference に Go! タイムテーブルの歩き方 for Gophers
mazrean
0
140
LLMは4年分のCompose移行を再現できるのか?実プロダクト279件のXMLで探る自動化の境界線
makun
0
540
標準パッケージに uuid が追加された 背景から見る Go らしい意思決定 / go_127_uuid_decision
convto
5
6k
Featured
See All Featured
The Spectacular Lies of Maps
axbom
PRO
1
990
Building Applications with DynamoDB
mza
96
7.2k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.3k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
690
From π to Pie charts
rasagy
0
360
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.4k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
4
620
Leo the Paperboy
mayatellez
9
2.3k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
Statistics for Hackers
jakevdp
799
230k
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冊売れた