Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ModelingKai 第3回 Event Storming (Design Level)

t2-kob
August 16, 2020

ModelingKai 第3回 Event Storming (Design Level)

#dddcj #ModelingKai で実施した勉強会で使用した、EventStorming の資料です。

第1回: https://speakerdeck.com/jnuank/event-storming-big-picturewoshi-su
第2回: https://speakerdeck.com/98lerr/eventstorming-softwaredesign-as-a-cooperative-game

t2-kob

August 16, 2020
Tweet

More Decks by t2-kob

Other Decks in Programming

Transcript

  1. いまドコ? 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回
  2. 今日のゴール Software Design レベル の Event Storming を行う ことで・・・ •

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

    境界づけられたコンテキストの詳細に飛び込めるようになり、 十分な設計のビジョンが手に入る。 • コーディングを始められるようになる。
  4. 前提条件 (Software Design レベル) • 参加者がコンテキストを共有できていること ◦ これは第2回(Process Modeling レベル)

    の図を見ればOK。 ◦ 新規の参加者さんが来てくださった場合は、ここで少し時間をとって振り返りをします。
  5. 1. UX モックアップのふせんを張る • 白色のふせん。 • UI/UX がどんな感じになるか絵や文字で表現します。 • Read

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

    Model の後ろに貼る。 ただし 下記の理由から "やらないでヨシ!" と判断 します。 • 2020年8月現在、このふせんを活用している記事はほぼ見当たらない。 ◦ 全部入りの図にしか出てこないことが多い。いつやるのかも何となくマチマチ。 • 原著でも完成度10%の章にチラっと載っているだけ。 • 著者のスライド(2017年, https://www.slideshare.net/ziobrando/50000-orange-stickies-later) にも存在しない。 ◦ タイトルが 『5万のオレンジのふせんのあと』 なので、経験則で不要になったっぽい? ただし「私は」という但し書き付き。 みんなで決めよう!
  7. 2. 集約のふせんを貼る • 薄黄色(Pale Yellow) のふせん。 ◦ コマンド(水色) と イベント(オレンジ)

    の間に配置。 ◦ ※ 同じ位置に配置するものに、 外部システム(ピンク) がある。 ◦ ステートマシンロジックを表す。 ▪ 状態遷移に伴う状態の変化/制約を充足することを保証するロジックのこと。 ◦ 『ふるまい』に着目する。データには着目しない。 • 直感に頼ると失敗するので、名前付けは後でする。 ◦ まず以下の質問に答える (※ 追加のふせんや紙に書いておくと Good)。 ▪ この薄黄色のふせんの責任は何ですか?(何をした結果、イベントが発生しますか? ) ▪ それに対するシステムの期待は? ▪ その責任を果たすために必要な知識は? ◦ これらの答えが明らかになったら自問する。 ▪ このクラスとその目的・含まれる情報をどのように呼べばよいか? https://www.slideshare.net/ziobrando/50000-orange-stickies-later
  8. 3-2. 【オプション】境界付けられたコンテキストに点数をつける • Greg Yang さんお勧めの方法。 • 何がコアコンテキストで、どこに DDD を適用するべきかを分析したい。

    ◦ ある境界付けられたコンテキストは、 DDD を適用すると競争上の優位性を得られる。 ◦ 一方、DDD による実装の複雑さとコストが目立ってしまう場合もある。 • そのため、各境界付けられたコンテキストに点数をつけて比較する。
  9. 3-2. 【オプション】境界付けられたコンテキストに点数をつける • プロダクトオーナーに質問をして回答をもらい点数付けすることで、 どの境界付けられたコンテキストから手を付けていくべきかを決定します。 ◦ チームが活用している点数付けの方法を使います。 ◦ 例えば、T-shirt sizing

    (S-L3段階, XS-XL5段階) や、プランニングポーカー値など。 • 質問1. ▪▪ は、ビジネス競争上の優位性にどのくらい貢献しますか? • 質問2. •• を 自動化するには、どのくらいの 複雑さ/コスト が必要ですか? ◦ ※ 質問2. はチームも一緒に考えます。 境界付けられたコンテキスト 優位性 複雑さ/コスト A B C
  10. 3-3. 【オプション】コアとなるコンテキストを決める • それぞれの境界付けられたコンテキストに点数がついたら… • ビジネス競争上の優位性が大きく、複雑さとコスト が高いものを探します。 ◦ それらの境界付けられたコンテキストが DDD

    適用時の焦点となります。 ◦ 複雑だが価値のあるもの = DDD を適用するとメリットが大きいもの。 ▪ 価値があっても簡単な場合、 DDD でなくても良いかもしれない (単純なCRUDとか)。 • 手を付けるべき『コアコンテキスト』が決定したらより詳しく分析します。 境界付けられたコンテキスト 優位性 複雑さ/コスト A  L   L  B M S C  L   S 
  11. 4. 図を再確認してみる • "Rewrite, then rewrite, then rewrite again." ◦

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