Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ドメインイベント増えすぎ問題
Search
ほりしょー
December 21, 2024
Programming
880
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ドメインイベント増えすぎ問題
ほりしょー
December 21, 2024
More Decks by ほりしょー
See All by ほりしょー
~ 秘伝のタレ化した『神スプシ』と戦う ~ 関数型パラダイムで壊れない仕組みへ
h0r15h0
1
190
Hello_LT_world_新年度前に振り返ろう_失敗から学んだ教訓_LT_Night___1_.pdf
h0r15h0
1
25
開発プロセスを継続的に改善する仕組み作り ~ 強いスクラムをいかに維持するか ~
h0r15h0
0
140
LLM(Copilot)を最大限活用するための取り組みとその副産物
h0r15h0
1
240
現実世界の事象から学ぶSOLID原則
h0r15h0
30
22k
集団意思決定の落とし穴と誰も望まない技術的負債
h0r15h0
1
5.4k
Goのパーサ作ってvscode拡張作ってみた!
h0r15h0
0
250
デザインパターンを学んだら世界が広がった話
h0r15h0
2
460
Other Decks in Programming
See All in Programming
ハーネス設計入門 〜プロンプト、コンテキストの次〜
kinopeee
47
30k
「人を評価する AI」の設計と実装
ryoyanara
0
270
まだ間に合う!今年の夏こそSchemeのマクロ展開器を完全理解!
omasanori
0
590
in-process GraphQL のすすめ #ginzajs
izumin5210
4
1.5k
go-spidermonkeyでAIエージェントのCode Modeを実装する
syumai
3
1.4k
書籍「プロフェッショナルAI駆動開発」紹介スライド
juntaromatsumoto
0
850
私のClaude Code活用法 (個人開発編) - PHPerKaigi mini #4(2026/08/24)
panda_program
1
190
LLMは4年分のCompose移行を再現できるのか?実プロダクト279件のXMLで探る自動化の境界線
makun
0
130
AIの中の人になってみる
htkym
0
150
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
180
片田舎のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PRを出すが、解決方法がキャッシュをしないようにすることであり、ビルド時間が伸びると言われてマージされないので高速化もする/swiftbuild
yimajo
0
330
異なる設計思想のフレームワークを経験して得た学び
amekuhideki
2
1.3k
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
My Coaching Mixtape
mlcsv
0
300
Marketing to machines
jonoalderson
1
5.7k
Test your architecture with Archunit
thirion
2
2.4k
Everyday Curiosity
cassininazir
0
300
The Cost Of JavaScript in 2023
addyosmani
55
10k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
710
Deep Space Network (abreviated)
tonyrice
0
280
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
510
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
490
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Transcript
2024/12/21 CQRS+ES カンファレンス 2024 ドメインイベント増えすぎ問題
ほりしょー ハコベル株式会社 サーバーサイドエンジニア @H0R15H0 https://youtu.be/ZFTW6Ete9eE?feature=shared https://zenn.dev/hacobell_dev/articles/131cbcb873e8ba https://zenn.dev/hacobell_dev/articles/4bf484a360d343
お話しすること ES運用から2年が経ち、 、 、 気がついたら似たようなドメインイベントが増えすぎていた 具体例を紹介 ドメインイベントを分割できたのでは?という気づき
トラックA トラックB 地点A 地点B 地点C ドメインイベント増えすぎ問題 トラックのルート組みを例に考える ルート組み全体で1集約
トラックA トラックB 地点A 地点B 地点C ドメインイベント増えすぎ問題 トラックのルート組みを例に考える ユーザはルートの最適化を行う ルートの組み替え=ドメインイベント
ドメインイベント増えすぎ問題 イベントパターン1:別のトラックにルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン1:別のトラックにルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン2:同一トラック内でルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン2:同一トラック内でルートを組み替える トラックA 地点A トラックB 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン3:新しいトラックを用意してルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン3:新しいトラックを用意してルートを組み替える トラックA トラックB 地点A 地点B 地点C トラックC
ドメインイベント増えすぎ問題 イベントパターン4:全地点同じトラックでルートを組む トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン4:全地点同じトラックでルートを組む トラックB 地点A 地点B 地点C トラックA
本当にバリエーションが必要だったのか? イベントパターン1:別のトラックにルートを組み替える イベントパターン2:同一トラック内でルートを組み替える イベントパターン3:新しいトラックを用意してルートを組み替える イベントパターン4:トラックを削除しルートを組み変える 💡ドメインイベントを分割するのはどうだろうか?
本当にバリエーションが必要だったのか? イベントパターン1:別のトラックにルートを組み替える イベントパターン2:同一トラック内でルートを組み替える イベントパターン3:新しいトラックを用意してルートを組み替える イベントパターン4:トラックを削除しルートを組み変える ↓ イベントパターンA:移動対象の地点をルートから削除する イベントパターンB:移動対象の地点をルートに追加する この2パターンの組み合わせで 1〜4
を表せないか?
ドメインイベント増えすぎ問題 イベントパターン1:別のトラックにルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン1:別のトラックにルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン1:別のトラックにルートを組み替える トラックA トラックB 地点A 地点B 地点C イベントA イベントB
ドメインイベント増えすぎ問題 イベントパターン2:同一トラック内でルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン2:同一トラック内でルートを組み替える トラックA 地点A トラックB 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン2:同一トラック内でルートを組み替える トラックA 地点A トラックB 地点B 地点C イベントA イベントB
ドメインイベント増えすぎ問題 イベントパターン3:新しいトラックを用意してルートを組み替える トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン3:新しいトラックを用意してルートを組み替える トラックA トラックB 地点A 地点B 地点C トラックC
ドメインイベント増えすぎ問題 イベントパターン3:新しいトラックを用意してルートを組み替える トラックA トラックB 地点A 地点B 地点C トラックC イベントA イベントB
ドメインイベント増えすぎ問題 イベントパターン4:全地点同じトラックでルートを組む トラックA トラックB 地点A 地点B 地点C
ドメインイベント増えすぎ問題 イベントパターン4:全地点同じトラックでルートを組む トラックB 地点A 地点B 地点C トラックA
ドメインイベント増えすぎ問題 イベントパターン4:全地点同じトラックでルートを組む トラックB 地点A 地点B 地点C トラックA イベントA イベントB
バリエーションを削減できた イベントパターン1:別のトラックにルートを組み替える イベントパターン2:同一トラック内でルートを組み替える イベントパターン3:新しいトラックを用意してルートを組み替える イベントパターン4:トラックを削除しルートを組み変える ↓ イベントパターンA:移動対象の地点をルートから削除する イベントパターンB:移動対象の地点をルートに追加する
一方で、分割することによるデメリットも イベント単体情報量は減ってしまう 移動したのか・削除されただけなのか不明瞭に 読み取りの結果整合性を考慮しなければならない 見えてはいけない状況ではないか? 実際のビジネスプロセスと乖離しすぎないか
まとめ・感想 ドメインイベントを分割するという発想 1ユーザ操作=1イベントの脳に凝り固まっていた イベントストーミング時点で気づきたかった 他に考慮すべき点がないか?