Event Storming (Design Level) Modeling-Kai 2020/08/16 

いまドコ？ https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming/83 今日は ここ (第3回) ※ 2020年現在、Process Modeling レベルを Software Design レベルの中に含む文献の方が多そうです。 　 しかし Modeling-Kai では 3レベル方式を採用 したので、少し流れが異なる場合があります。 第1回 第2回 

今日のゴール Software Design レベル の Event Storming を行う ことで・・・ ● 境界づけられたコンテキストの詳細に飛び込めるようになり、 十分な設計のビジョンが手に入る。 

今日のゴール Software Design レベル の Event Storming を行う ことで・・・ ● 境界づけられたコンテキストの詳細に飛び込めるようになり、 十分な設計のビジョンが手に入る。 ● コーディングを始められるようになる。 

前提条件 (Software Design レベル) ● 参加者がコンテキストを共有できていること ○ これは第2回(Process Modeling レベル) の図を見ればOK。 ○ 新規の参加者さんが来てくださった場合は、ここで少し時間をとって振り返りをします。 

実は前回からちょっとだけ図が変わりました ● かとじゅんさんに指摘をいただきました。 ○ 検索完了はイベントではなかった。 『ドメインの状態が変わったときに起こるのが イベントなので。検索完了しても予約の状態 は変わらないですよね。』 (抜粋) 

実は前回からちょっとだけ図が変わりました ● 正しくはこう(左側が消えた) 

今日やること(もうちょっと具体的に) 1. UX モックアップのふせんを貼る 2. 集約のふせんを貼る 3. 線を引いてドメインを区切る (境界付けられたコンテキストをつくる) 4. 図を再確認してみる 

Let's Storming! 

1. UX モックアップのふせんを張る ● 白色のふせん。 ● UI/UX がどんな感じになるか絵や文字で表現します。 ● Read Model の後ろに貼る。 ただし 下記の理由から "やらないでヨシ！" と判断 します。 ● 2020年8月現在、このふせんを活用している記事はほぼ見当たらない。 ○ 全部入りの図にしか出てこないことが多い。いつやるのかも何となくマチマチ。 ● 原著でも完成度10%の章にチラっと載っているだけ。 ● 著者のスライド(2017年, https://www.slideshare.net/ziobrando/50000-orange-stickies-later) にも存在しない。 ○ タイトルが 『5万のオレンジのふせんのあと』 なので、経験則で不要になったっぽい？ 

1. UX モックアップのふせんを張る ● 白色のふせん。 ● UI/UX がどんな感じになるか絵や文字で表現します。 ● Read Model の後ろに貼る。 ただし 下記の理由から "やらないでヨシ！" と判断 します。 ● 2020年8月現在、このふせんを活用している記事はほぼ見当たらない。 ○ 全部入りの図にしか出てこないことが多い。いつやるのかも何となくマチマチ。 ● 原著でも完成度10%の章にチラっと載っているだけ。 ● 著者のスライド(2017年, https://www.slideshare.net/ziobrando/50000-orange-stickies-later) にも存在しない。 ○ タイトルが 『5万のオレンジのふせんのあと』 なので、経験則で不要になったっぽい？ ただし「私は」という但し書き付き。 みんなで決めよう！ 

2. 集約のふせんを貼る ● 薄黄色(Pale Yellow) のふせん。 ○ コマンド(水色) と イベント(オレンジ) の間に配置。 ○ ※ 同じ位置に配置するものに、 外部システム(ピンク) がある。 ○ ステートマシンロジックを表す。 ■ 状態遷移に伴う状態の変化/制約を充足することを保証するロジックのこと。 ○ 『ふるまい』に着目する。データには着目しない。 ● 直感に頼ると失敗するので、名前付けは後でする。 ○ まず以下の質問に答える (※ 追加のふせんや紙に書いておくと Good)。 ■ この薄黄色のふせんの責任は何ですか？(何をした結果、イベントが発生しますか？ ) ■ それに対するシステムの期待は？ ■ その責任を果たすために必要な知識は？ ○ これらの答えが明らかになったら自問する。 ■ このクラスとその目的・含まれる情報をどのように呼べばよいか？ https://www.slideshare.net/ziobrando/50000-orange-stickies-later 

3. 線を引いてドメインを区切る ● ドメインイベントをサブドメインごとに分けてグループ化する線を引きます。 ● それぞれのグループに名前を付けます。 ● それらの一つ一つが『境界づけられたコンテキスト』になります。 イメージ https://buildplease.com/pages/fpc-6/ 

3-2. 【オプション】境界付けられたコンテキストに点数をつける ● Greg Yang さんお勧めの方法。 ● 何がコアコンテキストで、どこに DDD を適用するべきかを分析したい。 ○ ある境界付けられたコンテキストは、 DDD を適用すると競争上の優位性を得られる。 ○ 一方、DDD による実装の複雑さとコストが目立ってしまう場合もある。 ● そのため、各境界付けられたコンテキストに点数をつけて比較する。 

3-2. 【オプション】境界付けられたコンテキストに点数をつける ● プロダクトオーナーに質問をして回答をもらい点数付けすることで、 どの境界付けられたコンテキストから手を付けていくべきかを決定します。 ○ チームが活用している点数付けの方法を使います。 ○ 例えば、T-shirt sizing (S-L3段階, XS-XL5段階) や、プランニングポーカー値など。 ● 質問1. ■■ は、ビジネス競争上の優位性にどのくらい貢献しますか？ ● 質問2. ●● を 自動化するには、どのくらいの 複雑さ/コスト が必要ですか？ ○ ※ 質問2. はチームも一緒に考えます。 境界付けられたコンテキスト 優位性 複雑さ/コスト A B C 

3-3. 【オプション】コアとなるコンテキストを決める ● それぞれの境界付けられたコンテキストに点数がついたら… ● ビジネス競争上の優位性が大きく、複雑さとコスト が高いものを探します。 ○ それらの境界付けられたコンテキストが DDD 適用時の焦点となります。 ○ 複雑だが価値のあるもの = DDD を適用するとメリットが大きいもの。 ■ 価値があっても簡単な場合、 DDD でなくても良いかもしれない (単純なCRUDとか)。 ● 手を付けるべき『コアコンテキスト』が決定したらより詳しく分析します。 境界付けられたコンテキスト 優位性 複雑さ/コスト A 　L　 　L　 B M S C 　L　 　S　 

4. 図を再確認してみる ● "Rewrite, then rewrite, then rewrite again." ○ まだソフトウェアじゃない。 ■ サンクコストが気になるかもしれないけど、ふせん紙をゴミにするだけのこと。 ■ 精度を高めるためにイベントの名前を変更すると、他のコンポーネントも更新が必要になるかもしれない。 ■ 製品としてリリースしたらドメインイベントをアップデートするにはコストが掛かる。 まだ紙上なんだから、今のうちに直して (混乱して) しまおう。 ● Modeling-Kai 的には・・・ ○ みんな Event Storming 素人なので、完成前に確認タイムをとります。 ○ 時間が経ったことや、集約などを置いてみたことで何か間違いに気が付くかもしれません。 ○ 頭から声に出して読み合わせながら見直してみましょう。何か変なら直します。 確認しておきたいポイント: ReadModel, Command, External System, Aggregate, Event, Policy の 辻褄があっているか？ 

Event Storming Completed! 

GoTo Code! 

参考文献 ● https://www.slideshare.net/ziobrando/model-storming ● https://www.slideshare.net/ziobrando/50000-orange-stickies-later ● https://www.slideshare.net/ziobrando/software-design-as-a-cooperative-game-with-eventstorming ● https://buildplease.com/pages/fpc-8/ ● https://philippe.bourgau.net/why-should-we-use-design-level-event-storming-for-ddd/