どの抽象度からスタートするのか明確にする
スコープをコントロールしないと、モデリングは変に発散します。
これは従来のモデリング手法でも、イベントストーミングでも一緒です。
１つのシステムの内を構成する、論理境界間(モジュラーモノリス内の各モジュール間など)の連携を考えたいのか？
それとも、さらにマクロなシステム間連携のことを考えたいのか？
それによって、出すべき・議論するべきイベントの抽象度も変わってきます。
複数システム間の連携であるイベントを議論してるのに、
あるシステム内部の詳細なイベント要素を出してはいけない。
具体例
以下のようなオレンジ、青、緑のシステムからなるビジネスがあったと仮定する。
内部のイベントは簡単のために、２～３個にしてみた。
ここでは、システム間連携のイベントストーミングに関心があると読み取れます。
このくらいのイベント数ならば、上図のようにイベントを出してみてもいいが、
実際にはさらにイベント数は多いはずだ。
こんな時に、他システムと繋がってない、イベントBとかイベント②とかって
出す価値があると言えるだろうか？
ましてや、以下のような図はどうだろうか？
イベントBをさらに詳細化したものとして、イベントB-1、イベントB-2を出してみた。
こういった詳細は、本来オレンジのシステム境界内で情報隠ぺいしておくべきだ。
変にこうやって付箋に出してしまうと、最悪アクセスできた場合に、不要な動的結合を生んでしまいかねない。
なので、抽象度を揃えて、イベントを出すという鉄則に素直に従うのなら、
私なら以下のようにモデルを修正する。
ここまでの振り返り
モデルの抽象度を必ず明確にしましょう。
システム間連携のイベントであるならば、一段階詳細なサービス間連携のイベントは、別の詳細な図としてモデリングしましょう。
巷でよく言われるイベントストーミングは、
おおよそがマイクロサービスの各コンテキスト境界同士の連携をベースとしたイベント
の抽出に思える。
しかしながら、必ず「今から行うのは、どの抽象度でのイベントストーミングか？」
という問いかけをしましょう。
ちょっとした工夫
以下にわたしが過去にモデリングを案件の中でやってきて、
イベントストーミングに対して、こうしたらいいんじゃないか？っていう内容を列挙しておきます。
シーンによる違いを明確にする
置かれたシーンという前提条件の違いによって、イベントの順序が変わるという場合、
先にその 置かれたシーン という情報を出せるだけ出しておきましょう。
ただし、モデリングしていく中で、
「あ、ここ実は、こんな時とこんな時とで業務の形が変わるんです」
と判明したら、付箋で後から出すという形でもいいです。
そうやって、前提条件はモデリングしながら認識合わせするもんです。
最初から、前提をすべて揃えるなんて無理げーですので💦
まずは正常系のイベントを一通り出してみる
小さくゴールを見据えて始めるために、まずは異常系や代替フローは無視して、
ハッピーパスのみを考える。
異常系とかは、次のスプリントでもいい。
なぜなら
正常系の業務すら理解が浅い状態で、異常系なんて考えたら大混乱しやすいから。
異常系の業務は、正常系をはるかにしのぐ複雑さを持ちやすいです。
イベントストーミングに慣れてるとか、その業務に詳しいとか、認知負荷に強い人なら、
１回目のスプリントで、異常系まで出してしまってもいいでしょう。
ただし、当然出てくる付箋の量が尋常じゃないことになるので、
ワークショップ終わった時に、付箋が取っ散らかって、「あれ？結局なんだっけ？」とならないように。
イベントを出しながらすぐに時系列で並べる
イベントを網羅的に出してから時系列に並べるのではなく、この時点でイベント出しながら時系列に並べてしまう。
この時に定性的なチェックとして、ワークショップ参加者で声に出して読み合わせしながらやってみましょう。
声に出すか出さないかで批判的なチェックの出来栄えが全然変わってきます。
いったん思いつくイベントのみを出す
以下の図のように
コマンドやポリシー、アクターなどはいったん無視して、イベントのみを先に抽出してしまう。
これは、コマンドやポリシーがあることで、ノイズになり得るからです。
まずは、ビジネス上のイベント(事実)を登場させるのが優先事項です。
よって、イベント以外の要素はすべて無視します。
この時に、すべてのイベントを最初から付箋で出すのではなく(そんなん実際無理なので)、
まずは思いつくイベントを出し、時系列で並べたら、それを見ながらイベントをストーリー形式で議論してみましょう。
それによって、後から図のイベントの間にある、同じ抽象度の足りないイベントをあぶり出します。
たとえば、以下のような感じ。
ドメインの説明
まず最初に、参加希望者全員へあらかじめ自分の参加できる日時を入力した上で、
「いつがいいですか？」とお伺いを非同期で送ります。(Pub)
ここが一番左のイベントの 「勉強会の日程調整のお伺いがされた」 です。
この際には、Discordなどのチャネルをよく使ってます。
すると、参加希望者が次々と各々のタイミングで都度、そのメッセージを購読し(Sub)
自分のスケジュールを確認したのちに、
「自分はこの日がいい」「ちょっと今週は参加難しい」などのメッセージをDiscordチャネルに送ってきます。(Pub)
はい、ここで上記の図では取りこぼしてたイベントが１つ見つかりました。
参加希望者がイベントを出しています。
「参加可能な希望日時が回答された」 とでも一旦命名しておきましょう。
ただし、このイベントには、参加可能な日時がない場合には「参加できない」という表明が含まれます。
ということは、イベント名を私ならここですぐに、
「参加可能な希望日時が回答された」 から 「参加表明がされた(※)」 に書き直します。
この参加表明がされている途中、わたしは誰が入力し、誰が入力していないのか？を定期的にチェックします。(Sub)
その後、全員が参加表明の回答を終える(※※) と、
わたしがもっとも参加者の集中している日時を選定し、
その日時で開催日時と予習範囲の確定の連絡をします。
開催日時と予習範囲の確定の連絡という部分は、すでに２枚目の
「勉強会の開催予定日時と予習範囲が決定された」 で出ていますね。
しかしながら、※※部分のイベントは図で表現できていません。
全員分の「参加表明がされた」イベントの後に、
「勉強会の開催予定日時と予習範囲が決定された」イベントという順です。
ここまでの結果をもとにモデルを描きなおすと以下のようになってます。
連携方式を見える化する
イベント同士を結ぶ関連線で、同期なのか非同期方式なのか？を視える化しましょう。
上の図では、点線で結ばれてますよね？
これはすでに出した３つのイベント間は、非同期で連携しているってことを表してます。
もしも同期方式ならば、以下のように実線で表現します。
この時に、メッセージキュー、ブローカーなどの技術的な要素は出さないでおきましょう。
この事例はわたしが主催するクローズドな勉強会でのイベントを例として出してみた。
順番にこのドメインについて説明してみよう。
困ったら業務アクティビティを描く
口頭で言ってても、なかなか抜け漏れてるイベントに気づきにくい時もある。
そんな時には、サクッと詳細に入り込み過ぎないアクティビティ図を描いてみるといい。
マクロなイベントストーミングでわからない、
１つ１つのコンテキスト内部のフローは、１段階詳細なアクティビティ図でチェックしたらいい。
そしてすぐさま、１段階俯瞰したイベントストーミングの図に戻ればいい。
抽象がイベントストーミングのモデル図、１段階詳細なのがアクティビティ図
って立ち位置ですね。
ただし事前に概念モデリングを行っておくこと。
そうでないと、誰が登場人物で、そいつがどんなプロセスを実行するのかわかりにくいからだ。
UMLのアクティビティ図には、メッセージの送受信マークが標準で実装されている。
先っちょが尖ってる方が送信マークであり、凹んでる方が受信マーク。
これをもとに、以下のようにアクティビティ図を描いてみる。
このシグナルの送信/イベントの受信をもとに、イベントストーミングのイベントとして、
出すという工程も役立つと過去の経験から思っている。
この時に、アクティビティ図にはメッセージキューとかって描くんでなく、
あとから技術方式変えたくなる可能性を考慮して、
論理的な概念エージェントである、送信箱みたいな名前にしておきましょう。
補足
ちなみに、上記でできあがったモデルに対して、様々な角度で脅威モデリングしてみてください。
次回予告
次回は、効率よくイベントストーミングするための、他の思考との組み合わせや、業務改善との関係を書いていきます。