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
Learning_Domain-Driven_Design輪読会_#14.pdf
Search
issei
October 20, 2022
Programming
0
200
Learning_Domain-Driven_Design輪読会_#14.pdf
https://showcase-gig.connpass.com/event/262587/
LDDD輪読会14回目、チャプター12の資料です
issei
October 20, 2022
Tweet
Share
More Decks by issei
See All by issei
Learning Domain-Driven Design輪読会 #最終回
isseii10
0
100
Learning Domain-Driven Design輪読会 #17
isseii10
0
110
Learning_Domain-Driven_Design輪読会__10.pdf
isseii10
0
200
Other Decks in Programming
See All in Programming
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
1
160
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
24
7.3k
Ruby製社内ツールのGo移行
bgpat
2
260
設計の知識と技能で駆動するソフトウェア開発
masuda220
PRO
18
10k
Some Quick Ideas To Improve Your Tests ( #jassttokyo )
teyamagu
PRO
2
2.3k
Creating Retro-Style Photos Using Swift
ski
1
340
Understanding Ast By Looking
inouehi
0
120
document.write再考
brn
5
2.5k
フロントエンドパフォーマンス 入門
shouta2
7
1.5k
Enhancing Applications with Accessibility API
kishikawakatsumi
3
880
イベントストーミングによるオブジェクトモデリング・オブジェクト指向プログラミングの適用・開発プロセスの変遷・アーキテクチャの変革 / Object modeling with Event Storming.
nrslib
12
2.9k
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
1
120
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
58
4.9k
Unsuck your backbone
ammeep
660
56k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
225
51k
Debugging Ruby Performance
tmm1
68
11k
Raft: Consensus for Rubyists
vanstee
130
6.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
11
1.4k
It's Worth the Effort
3n
180
27k
How to train your dragon (web standard)
notwaldorf
71
5.1k
Web Components: a chance to create the future
zenorocha
304
41k
Agile that works and the tools we love
rasmusluckow
323
20k
Fontdeck: Realign not Redesign
paulrobertlloyd
75
4.8k
The Pragmatic Product Professional
lauravandoore
24
5.7k
Transcript
Learning Domain-Driven Design 輪読会 #14 Chapter 12. EventStorming 株式会社Showcase Gig
寺田 一生
はじめに • この資料は「Learning Domain-Driven Design」の Chapter 12を意訳・要約したものです • 資料の内容は原文の表現や内容と異なることがあり ます
Chapter 12. EventStorming • 今まで議論してきたソフトウェアデザインパターンやテクニックではなく、イベントス トーミングと呼ばれるローテクのモデリング手法について述べる • これまでの章で取り上げてきたDDDの核の部分をくっつけていく手法 • こんなことが分かる
◦ イベントストーミングのプロセス ◦ イベントストーミングの進行方法 ◦ イベントストーミングによって効果的にドメイン知識を共有したり、ユビキタス言 語を作ったりする方法
Overview 12.1 What Is EventStorming? 12.2 Who Should Participate in
EventStorming? 12.3 What Do You Need for EventStorming? 12.4 The EventStorming Process 12.5 Variants 12.6 When to Use EventStorming 12.7 Facilitation Tips 12.8 Conclusion 12.9 Exercises
12.1 What Is EventStorming?
12.1 What Is EventStorming? • グループでブレインストーミングし、ビジネスプロセスを素早くモデル化するローテクなやり方 • ビジネスドメイン知識をシェアする戦術的なツール • 一回のイベントストーミングにはスコープを設ける(そのグループが探索したいビジネスプロセス)
• 参加者はそのプロセスを付箋を使って時系列に沿った一連のドメインイベントとして探索していく • だんだんとそのモデルに概念が追加されていく ◦ アクター ◦ コマンド ◦ 外部システム ◦ などなど • ビジネスプロセスがどんな風に機能しているのかが上の要素からわかるようになるまで
12.2 Who Should Participate in EventStorming?
12.2 Who Should Participate in EventStorming? ワークショップの目的は、できるだけ短時間で多くのことを学ぶことだと心得 ておきたい。ワークショップにはキーパーソンを招待するが、彼らの貴重な 時間を無駄にしないようにしたい。 —
Alberto Brandolini イベントストーミングワークショップの創始者
12.2 Who Should Participate in EventStorming? • 理想的には、様々な人々がワークショップに参加すべき • 該当のビジネスドメインに関係する人であれば誰でもOK
◦ エンジニア ◦ ドメインエキスパート ◦ プロダクトオーナー ◦ テスター ◦ UI/UXデザイナー ◦ サポート担当 ◦ など • 異なったバックグラウンドの参加者が増えれば、より多くの知見が発見される • しかし、グループは大きくなりすぎないように注意したい • 全ての参加者がこのプロセスに貢献できるようにすべきだが、10人を超えると厳しくなっ てくるかもしれない
12.3 What Do You Need for EventStorming?
12.3 What Do You Need for EventStorming? • イベントストーミングは、ペンと大量の紙さえあれば良い •
イベントストーミングを円滑に行うためにあったら良いものを見ていきましょう • モデリングスペース ◦ まず初めに、大きなモデリングスペースが必 要 ◦ 壁一面をブッチャーペーパーで覆えばベストな モデリングスペースとなる ◦ 大きなホワイトボードでも代用できるが、でき る限り大きなものが良い ◦ 作ったモデリングスペースの全体を使うことに なるだろうから
12.3 What Do You Need for EventStorming? • 付箋 ◦
次に、豊富な色の付箋が大量に必要 ◦ 色は、ビジネスドメインの多様な概念を表現するのに使うので十分な色数 ◦ 量は、全参加者が自由に使えように十分な量を用意する ◦ イベントストーミングで一般的に使われる色については次のセクションで述べる ◦ 世の中のイベントストーミングの本やトレーニングと統一しておくために、可能なら色の 規則に従った方が良い • マーカー ◦ 付箋に書き込むためのマーカーも必要だ ◦ マーカーなどが少ないことが、知見共有のボトルネックにならないように十分な数のマー カーを用意する
12.3 What Do You Need for EventStorming? • お菓子 ◦
一般的にイベントストーミングは2~4時間続く ◦ エネルギー補給のためにヘルシーなお菓子も持っていこう • 部屋 ◦ 最後に、広い部屋も必要 ◦ 真ん中に大きいテーブルをおかないようにする ◦ 参加者が自由に動いてモデリングスペースを見るのを妨げないように ◦ 椅子は特にだめ ◦ 参加者には部屋の隅や輪の外にいてほしいわけでなく、ちゃんと参加して知見の共有を してほしいのでできれば椅子は部屋の外に出そう
12.4 EventStorming Process
12.4 EventStorming Process • イベントストーミングワークショップは 10ステップからなる • 各ステップを経るごとにモデルには情報や概念が付け加えられる ステップ1: Unstructured
Exploration / 非構造化探索(カオス探索) • これから探索を行うビジネスドメインに関連するドメ インイベントのブレインストーミングから始まる • ドメインイベントはビジネスで起こった興味深い出来 事のこと • ドメインイベントを過去形で表現するのが大事 • 図12.1のようにすでに起こったこととして記述する
12.4 EventStorming Process ステップ1: Unstructured Exploration / 非構造化探索 • ステップ1では、参加者全員オレンジ色の付箋を持って、思いついたドメインイベントは何でも書き
下し、貼り付ける • このような初めの段階では、イベントの順序で並べたり重複を気にしたりしなくて良い • ステップ1はビジネスドメインで起こり得ることをブレインストーミングすることが大事 • 新しいドメインイベントがなかなか出てこなくなるまで、やり続ける
12.4 EventStorming Process ステップ2: Timelines / タイムライン • 次に、作ったドメインイベントを確認しビジネスドメインで起こった順番に並べていく •
初めに整理するイベントは「ハッピーパスシナリオ」 (成功時のフロー)から • 次に他のシナリオも加えていく ◦ エラーが発生したパスや異なったビジネス上の意思決定をとったパス • このステップでは間違ったイベントを直したり、重複を無くしたり、もちろん必要であれば見 落としていたイベントを追加したりもする • フローの分岐は右図のように表せる
12.4 EventStorming Process ステップ3: Pain Point / ペインポイント • 時系列で並べられたら、注意が必要なプロセスの箇所を見つけるために俯瞰してみる
◦ ボトルネック ◦ 自動化を要するマニュアルなステップ ◦ ドキュメント化していない部分 ◦ ドメイン知識が足りていない部分
12.4 EventStorming Process ステップ3: Pain Point / ペインポイント • このような非効率的な部分を明らかにしておく
ことは重要 • イベントストーミングが進行しても戻って来やす くなるし、後で対処することもしやすくなるから • ペインポイントはダイヤ型のピンクの付箋を使う (右図) • もちろん、このステップがペインポイントを見つける唯一の機会ではない • ファシリテーターはイベントストーミングの最初から最後まで参加者の発言に気を配って おく • 問題や悩み事が挙がったら、ペインポイントとして記述する
12.4 EventStorming Process ステップ4: Pibotal Event / ピボットイベント • 次はコンテキストやフェーズが切り替わる重大なビジネスイベントを探す
• これは「ピボットイベント」と呼ばれ、その前後を縦線で区切る • 例えば図12-5のように「ショッピングカートを初期化した」、「注文を初期化した」、「注文を出荷し た」、「注文配送済み」は一つの注文を作成するプロセスで重大な変化 • ピボットイベントは境界づけられたコンテキストの境界となりうる箇所の指標となる
12.4 EventStorming Process ステップ5: Commands / コマンド • ドメインイベントがすでに起こったことを表すのに対し、コマンドは イベントやフローのトリガーとなる
ものを表す • コマンドはシステムのオペレーションを表現し、ドメインイベントとは全く違って 命令形で書く ◦ Publish campaign (キャンペーンをパブリッシュせよ) ◦ Roll back transaction (トランザクションをロールバックせよ ) ◦ Submit order (注文を出せ)
12.4 EventStorming Process ステップ5: Commands / コマンド • コマンドは水色の付箋に書き、それによって引き起こされるイベントの前段に置く •
もしコマンドが特定の役割を持つあるアクターによって実行される場合、アクターの情報を小さい黄 色の付箋で追記する(図12-6) • アクターは消費者、管理者、編集者などのようなビジネ スドメインのユーザーペルソナ • 当然コマンドとアクターは必ずしも一対一ではないので 明確な時だけアクター情報をつける • 次のステップで、モデルにコマンドのトリガーを付け加 える
12.4 EventStorming Process ステップ6: Policies / ポリシー • コマンドは大体モデルに付け加えられるが、特定のアクターがいない場合がある •
このステップではそのようなコマンドを実行するオートメーションポリシーを見つける • オートメーションポリシーとは、あるイベントがコマンドのトリガーとなるシナリオのこと • 言い換えると、特定のドメインイベントが起こった時に自動的にコマンドが実行される
12.4 EventStorming Process ステップ6: Policies / ポリシー • ポリシーは紫の付箋で表し、イベントとコマンドをつなげ る(図12-7)
• もし該当のコマンドがある判断基準を満たした時のみ引 き起こされるなら、それを付箋に書く • 例えば、「クレームを受け取った」イベントの後に、それ がVIPの消費者からのクレームの時のみ「エスカレート」 のコマンドを起こしたい、という場合はポリシーに「 VIP の消費者のみ」と書く • 位置的にイベントとコマンドが離れているなら矢印で繋ぐ
12.4 EventStorming Process ステップ7: Read Models / リードモデル • リードモデルはアクターがコマンドの実行を決めるドメインのデータのビュー
◦ システムのスクリーン ◦ レポート ◦ 通知 ◦ など • 図12-8のように、緑の付箋で、アクターの決定をサポートするのに必要な情報のソースの短い記述 を書き、コマンドの前段に貼る
12.4 EventStorming Process ステップ8: External Systems / 外部システム • 外部システムとのモデルに拡張する
• 外部システムとは探索しているドメインに含まれないも の • コマンドを実行したり(インプット)、イベントを通知したりする(アウトプット) • 図12-9のようにピンクの付箋で表す • 外部システムであるCRMは「注文を配送せよ」コマンドの実行のトリガーとなる • 「配送が承認された」とき、ポリシーを通じて CRMに知らせる • このステップで最終的に全てのコマンドはアクターに実行されるか、ポリシーによってトリガー されるか、外部システムによって呼ばれるかのどれかになる
12.4 EventStorming Process ステップ9: Aggregates / 集約 • 全てのイベントとコマンドが表現されたら、参加者は関連する概念を集約させる •
図12-10のように、集約には大きめの黄色の付箋を使い、左にコマンド、右にイベントを置く
12.4 EventStorming Process ステップ10: Bounded Contexts / 境界づけられたコンテキスト • 最後のステップは集約どうしの関係を探す
• 集約どうしは機能的に密接に関係しているか、ポリシーを通じて分けられている • 図12-11のように、境界づけ られたコンテキストの境界の 候補が自然に現れる
12.5 Variants
12.5 Variants • イベントストーミングの創始者の Alberto Brandoliniは、イベントストーミングをルールが厳しくない ガイダンスだと定義している • 自分にあったベストな「レシピ」を見つけるために、自由にプロセスを試してみてほしい •
著者の経験では、組織にイベントストーミングを導入するときは、ステップ 1(カオス探索)からステッ プ4(ピボットイベント)に従ってビジネスドメインの全体像を探索するのが良さそう • 出来上がるモデルはその企業のビジネスドメインを広くカバーし、ユビキタス言語の強固な基盤を 構築し、境界付けられたコンテキストの境界の候補を出す
12.5 Variants • このような大きいモデルが完成し、色々ビジネスプロセスが見つかった後で関係のあるビジネスプ ロセスそれぞれについても全てのステップを通したイベントストーミングを行う • イベントストーミングが終わる時、ビジネスドメインイベント、コマンド、集約、境界の候補を表すモ デルが得られるはず • しかし、これらはいいおまけでしかなく、大事なのはプロセスそのもの
◦ ステークホルダー間で知見の共有 ◦ 思っているビジネスモデルの整理 ◦ 矛盾するモデルの発見 ◦ ユビキタス言語の策定
12.5 Variants • 結果得られるモデルは、イベントソースドメインモデルを実装するための基礎として採用すること ができる • このルートをとるかどうかの判断は、ビジネスドメインに依存する • イベントソースドメインモデルを実装すると決めた場合、境界付けられたコンテキストの境界、集 約、そして必要なドメインイベントの設計図を手に入れられる
12.6 When to Use EventStorming
12.6 When to Use EventStorming • ワークショップは多くの理由から進行される ユビキタス言語の策定 • グループでビジネスプロセスのモデルを構築していくうちに、用語がシンクロして同じ言葉を使
うようになっていく ビジネスプロセスのモデル • ビジネスプロセスのモデルを構築するのにイベントストーミングは効果的 • DDDに基づいているので、集約や境界づけられたコンテキストの境界を見つけやすい
12.6 When to Use EventStorming • ワークショップは多くの理由から進行される 新たなビジネス要件の探索 • 新しい機能に関して参加者全員が同じ考えを持っていることを確認し、ビジネス要件でカバー
されていないエッジケースを明らかにすることができる ドメイン知識のリカバー • 時間が経つとドメイン知識は失われうる • モダンにする必要があるようなレガシーなシステムではこれが特に深刻 • イベントストーミングはそれぞれの参加者の持つ知識を統合し、一つの像にするのに効果的
12.6 When to Use EventStorming • ワークショップは多くの理由から進行される 今あるビジネスプロセスの改善 • ビジネスプロセスの全体像をつかむことで、非効率に気づく視点とプロセスを改善する機会が
得られる 新たなチームメンバーのオンボーディング • 新メンバーとイベントストーミングをすることは、新メンバーのドメイン知識を広げるのにすごく いい方法
12.6 When to Use EventStorming • どんな時にイベントストーミングを使わないかも覚えておくのは重要 • ビジネスプロセスがシンプルで明確な時には効果が少ないかも ◦
興味深いビジネスロジックや複雑さなしで淡々と順番に行われるようなプロセス
12.7 Facilitation Tips
12.7 Facilitation Tips • イベントストーミングが初めてのグループでは、イベントストーミングの概要を簡単に掴むことから 始めるのが良い • 何を行うのか、探索しようとしているビジネスプロセス、ワークショップで用いるモデリング要素に ついての説明から始める •
ドメインイベント、コマンド、アクターなどの要素を説明してい くと図12-12のような判例ができる • 色の規則を覚えておくのに役立つ • ワークショップ中ずっと、参加者から見えるようにしておく
12.7 Facilitation Tips • イベントストーミングが初めてのグループでは、イベントストーミングの概要を簡単に掴むことから 始めるのが良い • 何を行うのか、探索しようとしているビジネスプロセス、ワークショップで用いるモデリング要素に ついての説明から始める •
ドメインイベント、コマンド、アクターなどの要素を説明してい くと図12-12のような判例ができる • 色の規則を覚えておくのに役立つ • ワークショップ中ずっと、参加者から見えるようにしておく
12.7 Facilitation Tips Watch the Dynamics • ワークショップを進行するとき、グループの熱量を監視するのが大事 • 盛り上がりが落ち着いたとき、質問を投げかけることで再点火させるか、次のステップに移るかを
考える • イベントストーミングはグループ活動だということを忘れずに • 全員がモデリングと議論に参加する機会があることを確認する • 一部の参加者がグループから遠ざかっていたら、モデルの今の状態について質問することで、巻 き込むようにする • イベントストーミングは激しい活動で、どこかで休憩が必要となる • 参加者全員が部屋に戻るまでは、再開しない • 今のモデルの状態を確認しながら再開し、グループを協調的なモデリングムードに戻す
12.7 Facilitation Tips Remote EventStorming • 創始者Alberto Brandoliniはリモートで行うことに意義を唱えている • リモートではオフラインと同じレベルでの参加や協力や知識共有ができないから
• しかし、コロナ禍でオフラインも厳しい • 執筆時点では、オンラインで行う時のツールとして最も注目すべきは miro • オンラインではよりしんぼう強く、また効果的なコミュニケーションが少なくなることを考慮に入れる • 著者の経験では、対面時より参加者を少なくするのが良い • 対面では10人程度だったが、オンラインは5人までにするのが好ましい • 参加者が多くなってしまう場合は、複数のイベントストーミングを進行する • その後、結果のモデルを比較、統合するのもあり
12.8 Conclusion
12.8 Conclusion • イベントストーミングは、ビジネスプロセスをモデリングするための共同で行うワークショップ • 一番のメリットは、結果として得られるモデルではなく 知識の共有 • イベントストーミングが終わる頃には、 参加者の個々で思っていたビジネスプロセスのモデルがシ
ンクロし、ユビキタス言語を使い始める初めの一歩 となる • イベントストーミングは自転車に乗るのに似ている • 本を読むより実際にやってみるのがはるかに簡単 • ワークショップは楽しいし、進行も簡単 • 始めるのに黒帯は必要ない • 進行して、ステップに沿って、プロセスを学ぶだけ
12.9 Exercises
12.9 Exercises 1. イベントストーミングの参加者としてどんな人を募ればいいですか? a. ソフトウェアエンジニア b. ドメインエキスパート c. QAエンジニア
d. 探索するビジネスドメインの知識をもったステークホルダーみんな
12.9 Exercises 1. イベントストーミングの参加者としてどんな人を募ればいいですか? a. ソフトウェアエンジニア b. ドメインエキスパート c. QAエンジニア
d. 探索するビジネスドメインの知識をもったステークホルダーみんな
12.9 Exercises 2. イベントストーミングをやってみるのにいい機会なのはどんな時ですか? a. ユビキタス言語を策定したいとき b. 新たなビジネスドメインを探索したいとき c. もうあるプロジェクトの失われた知識を取り戻したいとき
d. 新規チームメンバーを導入したいとき e. ビジネスプロセスを最適化する方法を見つけたいとき f. 上記全て
12.9 Exercises 2. イベントストーミングをやってみるのにいい機会なのはどんな時ですか? a. ユビキタス言語を策定したいとき b. 新たなビジネスドメインを探索したいとき c. もうあるプロジェクトの失われた知識を取り戻したいとき
d. 新規チームメンバーを導入したいとき e. ビジネスプロセスを最適化する方法を見つけたいとき f. 上記全て
12.9 Exercises 3. イベントストーミングの成果物として何が期待できますか? a. ビジネスドメインのより良い共通認識 b. ユビキタス言語の強い基盤 c. ビジネスドメインの理解で足りていない部分を明らかにする
d. ドメインモデルの実装に使えるイベントベースドなモデル e. イベントストーミングを行う目的にも依るが、上記全て
12.9 Exercises 3. イベントストーミングの成果物として何が期待できますか? a. ビジネスドメインのより良い共通認識 b. ユビキタス言語の強い基盤 c. ビジネスドメインの理解で足りていない部分を明らかにする
d. ドメインモデルの実装に使えるイベントベースドなモデル e. イベントストーミングを行う目的にも依るが、上記全て