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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ほりしょー
December 21, 2024
Programming
2
850
ドメインイベント増えすぎ問題
ほりしょー
December 21, 2024
Tweet
Share
More Decks by ほりしょー
See All by ほりしょー
開発プロセスを継続的に改善する仕組み作り ~ 強いスクラムをいかに維持するか ~
h0r15h0
0
120
LLM(Copilot)を最大限活用するための取り組みとその副産物
h0r15h0
1
200
現実世界の事象から学ぶSOLID原則
h0r15h0
30
21k
集団意思決定の落とし穴と誰も望まない技術的負債
h0r15h0
1
5.2k
Goのパーサ作ってvscode拡張作ってみた!
h0r15h0
0
210
デザインパターンを学んだら世界が広がった話
h0r15h0
2
410
Other Decks in Programming
See All in Programming
守る「だけ」の優しいEMを抜けて、 事業とチームを両方見る視点を身につけた話
maroon8021
3
1.1k
コードレビューをしない選択 #でぃーぷらすトウキョウ
kajitack
3
1k
モックわからないマン卒業記 ~振る舞いを起点に見直した、フロントエンドテストにおけるモックの使いどころ~
tasukuwatanabe
3
400
「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜
kentaroutakeda
3
970
go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ
arthur1
2
570
nuget-server - あなたが必要だったNuGetサーバー
kekyo
PRO
0
280
AWS×クラウドネイティブソフトウェア設計 / AWS x Cloud-Native Software Design
nrslib
16
3.3k
CSC307 Lecture 15
javiergs
PRO
0
260
ベクトル検索のフィルタを用いた機械学習モデルとの統合 / python-meetup-fukuoka-06-vector-attr
monochromegane
2
480
それはエンジニアリングの糧である:AI開発のためにAIのOSSを開発する現場より / It serves as fuel for engineering: insights from the field of developing open-source AI for AI development.
nrslib
0
290
Everything Claude Code OSS詳細 — 5層構造の中身と導入方法
targe
0
130
Go Conference mini in Sendai 2026 : Goに新機能を提案し実装されるまでのフロー徹底解説
yamatoya
0
610
Featured
See All Featured
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
250
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
690
Building the Perfect Custom Keyboard
takai
2
710
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.7k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
150
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.4k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
74
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
74
Exploring anti-patterns in Rails
aemeredith
2
290
Everyday Curiosity
cassininazir
0
170
Darren the Foodie - Storyboard
khoart
PRO
3
2.9k
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イベントの脳に凝り固まっていた イベントストーミング時点で気づきたかった 他に考慮すべき点がないか?