EventStormingをやってみた話

はじめに

この記事について

DDD-Community-jp 内で行っているモデリング会で、EventStormingをやってみた体験談です。

やってみて、いいと思ったこと、ぶつかったこと/悩んだことの紹介になります。
「正しいやり方の紹介」ではない点はご注意ください。
（この段階でこう考えたがあとで修正、などは書くようにしてます)

やってみての EventStorming の感想

記事が長くなるので、最初に感想を。

以下の点で、とても強力なツールと感じました。

• プロセスが視覚化され、チーム内で意見がぶれるところを発見し、意識統一していける。
• 集約が簡単に導き出せる。

一方で、以下の点は EventStormingの外で頑張らないといけないと感じました。

• 要件を出すものではない。別で要件分析が必要そう。
• コード化する際、CQRS+ESが前提になりそう。

EventStorming を実施した背景

• 会議室予約ドメイン をモデリングする会の中で、以下のような課題が出てきました。
  • 用語の怪しさ
  • 集約/リポジトリの怪しさ

例: 予約には成立する前の状態、成立後の状態があるのでは？
--> 成立前はなんと呼ぶ？ 予約希望？
--> 予約希望を作る、というのは正しい処理？ 「予約希望する」って言葉の意味通る？
--> 予約希望 と 予約(成立したもの) は 同じ集約？ 別集約？ リポジトリは?
--> 予約する(動詞) vs 予約(名詞) の混在。

• コト、モノ、ヒトを整理しよう。EventStorming を使ってみようということではじめました。

EventStorming について

どういうもの？

• Alberto Brandolini 氏が提唱するモデリング手法です。
  • EventStorming
• 複雑なビジネスドメインから、ワークショップを通してモデルを作ることができます。

進め方

• 3つのSTEPでモデリングしていきます。 (それぞれのリンク先は、会で使用した資料)
  • BigPicture
    • jnuankさん/Event Storming Big Pictureを試す
  • Process Modeling
    • EventStorming SoftwareDesign as a Cooperative Game
  • SoftwareDesign
    • t2-kobさん/ModelingKai 第3回 Event Storming (Design Level)

(Software design as a cooperative game with EventStorming, Alberto Brandolini)

これ以降、それぞれのステップについて以下3点を述べていきます。

• やること: EventStorming の進め方概要。詳細は上のスライドリンクで。
• やった結果: モデリング会でできたアウトプット。
• やってみて: やってみた感想。嬉しかったこと、難しかったこと。

Big Picture

やること

1. カオス探索

• イベントになりそうなものを出して並べる
• 懸念事項は付箋で近くに貼っておく
• タイムラインの精査
  • イベントを時系列順に並べ直す
• 人とシステムの明示
  • 関連する人、外部システム
• ウォークスルー/逆向きナラティブ
  • 前から、後ろから読み上げて違和感を見つける
• 問題と機会
  • フロー全体を見て、問題あるところ、解決策を出していく

やった結果

オレンジの付箋で「イベント」を挙げて、タイムラインに沿って並べました。
イベントの状況に合わせて、スイムレーンを分割しています。
ちなみに、おばちゃんは会議室の管理者です。

「やってみて」に背景を書いてますが、次の「Process Modeling」で出す「Command(青い付箋)」がこの段階で出てきました。

やってみて

• 嬉しいこと
  • 言葉が整理できました。名詞、動詞それぞれ用語が揃えられました。
    • 例: "予約" は名詞として扱う。
    • 例: 予約の確定を "成立する" という動詞にする。
• 難しいこと
  • Eventって何、がブレました。
    • まずEvent、と出していくと、主語が人になったりシステムになったりまちまち。
      • 途中で主語が人のものを 「Command(青付箋)」 に書き換えました。
      • 「アクターの動き(コマンド)と、 その結果起きること(イベント)」で整理。
      • この問題は、最後の 「Software Design」まで続きます。
    • 最初は、主語を含めて付箋に書いた方が良さそうでした。
    • 人(黄色付箋)を追加すると、Commandには主語が不要になってきます。
  • 分岐するようなイベントをどう表現するか、分からずじまいでした。
    • いったん並べて書いています。
    • この悩みも解決は「Software Design」まで持ち越しです。

Process Modeling

やること

Cooperative Gameという名前がついてます。
並んだEventの前後に付箋を追加し、プロセスパスを完成させていきます。

プロセスパスを作るのは前からでも、後ろからでも、それぞれのEventを始点にしても良いです。
今回は、一番わかりやすいと言われる「前から」の手段を取りました。

1. Event が始まる起点を考える。 (リアルワールドの要件、Eventを求める人など)
2. 要求を Command で配置する。
3. 色文法にしたがって、付箋を配置していく。
   • 青->ピンク->オレンジ->紫->青...
   • Commandの後ろには System をおく。今回はExternal限定の縛りはなし。
   • Event と Command の間には 必ず Policy を置く。文法を守る。
   • まずはワンパス通すことを目標とする(Rush to the Goal)。議論が出たら HotSpot(菱形付箋)を置いて後回しにする。
4. 最後 System Happy (もうやることがない) & User Happy (可能な範囲で幸せな状態/なんらかの結果を得ている) になったらプロセスは終了。
5. HotSpotに戻って、問題を潰していく。

やった結果

一通り色文法通りに並びました。
「Policyにはビジネス判断がある」という文をもとに、この回は分岐の役割をここにしましたが、これは次の「SoftwareDesign」で修正されます。

ただ、終わったあとで「イベントがドメインの変化を表してない」とのご指摘をいただいて修正。

検索など、読み取り処理は何も変化を表していない → ドメインイベントではないですね。

やってみて

• 嬉しいこと
  • カラフルになって、出来上がってきた感はしてきました。
  • BigPictureよりも詳細に視覚化されるため、前回以上に「認識がぶれているところ」が見える(議論できる)ようになりました。
• 難しいこと
  • ここでもEventとは何、がぶれています。
    • ReadするCommandが生成するEvent、という話が出てきたり。
    • やっている最中、この検索処理の位置付けが分からなくで大分悩みました。
    • 結論は前述の通り、「ドメインに変化を与えないものはイベントでない」
  • Policyが最初、何を意味するか分かりませんでした。
    • 最初書くと、省きたくなります。ただし、著者の資料でも「Policyを省くな」と書かれています。
    • 省きたくなる衝動を抑えてしばらく議論すると、暗黙ポリシーがだんだん見えてきました。
    • この見えてきたPolicyに怪しい要素がいろいろ出てくるので、まず置いてみるのは大事ですね。

Software Design

やること

1. UIモックアップを追加(最近やらない記事も多いので、今回省略)

• Aggregateの付箋を貼る
  • system付箋のうち、Externalでないものを置き換える。
• Aggregateの質問に答える
  • 「このAggregateの責任は何ですか？」
  • 「それに対するシステムの期待は？」
  • 「その責任を果たすのに必要な知識は？」
• ドメインを区切る(今回やった中では切れる範囲なし)

やった結果

予約変更、予約削除は同じ内容の繰り返しになりそうなので省略です。
ここまできて、「これ、ワークフローっぽくない？」「作りたいシステムはこれ？」というのが見えてきました。

過去にずっと悩んできた「分岐」は、ここにきてようやく「Aggregate」がやるもの(そしてパターン別のドメインイベントを発生させる)ということが見えました。

EventStorming としてはここでまたBigPictureに戻って…の繰り返しのようですが、会としては戻る前に一旦「要件を整理し直してやりたかったことを考えよう」となりました。

やってみて

• 嬉しいこと
  • 集約が見つけやすい。集約の責務、必要知識と合わせて整理していくのに有効なのを体感できました。
  • ここまできて、BigPicture、ProcessModelingで悩んでいた問題が解決。すっきりした分も多いです。
    • 分岐はAggregateで表現する。
    • PolicyはAggregateに渡すまで(when/then. 暗黙か明示かの違いはある)
  • Command - Aggregate - Event の関係性でまとめて話した方が結論に向かえますね。
• 難しいこと
  • Process Modeling のステップは必要だったかが疑問。
    • 最近だと 「Process Modeling」「Software Design」 を分けない資料もあります。
    • 「Process Modeling」で一旦「Externalでない」Systemもおいたが、段階踏む必要があったかは疑問です。
  • 最初からDDDの言葉でやると迷いやすいかもしれないです。
  • 終始、主語は誰？は悩みの種でした。

全部やってみて

冒頭に述べた通り、意識合わせや集約の発見にはとてもパワフルな手法でした。
また作りたいもの視覚化により、コードに進む前に解決すべき問題が見えてきたのもメリットと思います。

以下は、当日参加したメンバーでの振り返りです。

追記

追記1 LDDD本紹介

LDDD本 (Learning Domain Driven Design, Vlad Khononov) で EventStorming の内容について記載がありましたので、一枚絵でまとめました。
Step.1 は、直訳で「過去形」と書いてしまいましたが、「過去完了形」と言った方が日本人にとっては正しいです。
Step.7 は、リードモデルですね。。。Google翻訳で読んでたのバレバレ。恥ずかしいデータが残ってしまった。

今日の #ModelingKai でEventStorming入るかもなので、LDDD本式のやり方まとめてみた。
ちょっと１枚で描くの狭い？？

本は例もつけてくれてて、以前元の本で悩んだとこがわかりやすかった。結構やり方違うけど。
4, 9, 10あたりは、本の説明でもちょっと苦しい気が…この辺は慣れるしかないかなー。 pic.twitter.com/7Q0jF78tn6

— 98lerr (@98lerr) April 24, 2022

LDDD本は、 こちら をご参照ください。
具体例なども含めて書かれてるので、よりしっくりくると思います。この絵は、本を読む時の参考に使っていただければと。

追記2

集約を見つけるときに、「手前にビジネスルールを黄色付箋(集約付箋の半分サイズ)で置く」というやり方があり、実際とてもやりやすかったです。
認識が合わせやすかったり、見落としに気付けたり。
ひとまず、おすすめページとしてリンクをつけておきます。

上の Twitter投稿の絵に反映したのが、以下の絵です。