イベントストーミングのメモ

Introducing EventStormingを読んだ際のメモです。

イベントストーミングとは

イベントストーミングは、複雑なビジネス領域(ドメイン)を共同で探求するための柔軟なワークショップのフォーマットです。

イベントストーミングの目的

• 既存事業ラインの健全性を評価し、最も効果的な改善領域を発見するため；
• 新規スタートアップビジネスモデルの実行可能性を探るため；
• 関係する全ての当事者に最大限の好結果をもたらす新サービスを構想するため；
• 急速に進化するビジネスを支える、クリーンで保守性の高いイベント駆動型ソフトウェアを設計するため。

関係者を一同に集めてビジネスドメインのプロセスの俯瞰図(Big Picture)を作成することで、上記の目的を達成します。

イベントストーミングの基本要素

• ドメインイベント(Domain Event): ビジネスドメインにおける重要な出来事。過去形で書く。オレンジ色のポストイットで表現。
• コマンド(Command): ユーザーの操作やポリシーに基づいて実行するアクション。ドメインイベントの命令形で書く。○○されたに対して○○するになる。青色のポストイットで表現。
• ポリシー(Policy): ビジネスルールや条件に基づくアクション。ドメインイベントの後にくる。紫色のポストイットで表現。
• システム(System): システムの要素。コマンドを実行するものや、ドメインイベントを発生させるもの。ピンク色のポストイットで表現。
• ユーザー(User): システムを利用する人。小さな黄色のポストイットで表現。
• リードモデル(Read Model): コマンドを発生するための決定を下すための情報。緑色のポストイットで表現。
• 時間軸(Time Line): ドメインイベントの発生順序を示す線。

イベントストーミングの進め方

1. 準備: 大きなホワイトボードや壁、カラフルなポストイット、マーカーを用意する。
2. ドメインイベントの洗い出し: 参加者全員でビジネスドメインにおける重要な出来事を洗い出し、オレンジ色のポストイットに書いて貼り付ける。
3. 時間軸の作成: ドメインイベントを発生順に並べ、時間軸を作成する。スイムレーンを使って異なるプロセスや関係者を区別することも可能。
4. pivotポイントの特定: 重要な転換点や意思決定ポイントを特定し、強調する。
5. ウォークスルー: 参加者全員で時間軸に沿ってドメインイベントを順に声を出して確認する。その後、時間軸を遡って各ドメインイベントに対して「なぜそれが起こったのか？」を問いかける。
6. コマンドの追加: 各ドメインイベントに対応するコマンドを青色のポストイットに書いて貼り付ける。
7. ポリシー、システム、ユーザー、リードモデルの追加: 必要に応じて、それぞれの要素を対応する色のポストイットに書いて貼り付ける。
8. 関係性の明確化: 矢印や線を使って、各要素間の関係性を示す。
9. 分析と改善と実装: 作成したモデルを基に、ビジネスプロセスの改善点や新しいアイデアを議論し、ソフトウェアの実装に活用する。

注意事項

• 全員の意見を尊重し、積極的に参加することが重要。合意したものを書き出すのではなく、相違を洗い出すために重複も許容する。
• 声を出して確認することで、馬鹿げたプロセスに気づくことがある。
• 名詞ではなく動詞に焦点を当てる。
• 議論が噴出した場合は、ホットスポットとしてマークし、後で別途議論する。
• ハッピーパスを優先し、例外処理は後回しにする。

ソフトウェア設計イベントストーミング

(Software Design EventStormingより)

通常のイベントストーミングに加えて、以下の要素を追加します。

• バウンデッドコンテキスト(Bounded Context): ドメインの一部であり、特定のモデルが適用される範囲。境界を示すために太い線で囲む。
• アグリゲート(Aggregate): 集約。データコンテナというよりも、ステートマシンに似ている。薄い黄色のポストイットで表現。

所感

ドメイン駆動設計を実践しようとするとどうしても集約に目が行きがちで集約の設計は難しい。イベントストーミングが注目されたのは、まずはドメインイベントを洗い出すことに集中する事で最終的に集約の設計に繋がるからだろう。

名詞ではなく動詞を重視するというのは重要な視点である。つまり、データオブジェクトではなく関数に注目するということだ。関数型プログラミングの考え方にも通じる。また集約はステートマシンになるというのも興味深い。ステートを代数的データ型(ADT)で表現し、状態遷移を純粋関数で表現するような設計ができれば、集約の設計もシンプルになるのではないかと考えた。

ドメイン駆動設計はオブジェクト指向ソフトウェアの開発者向けの方法論として提唱された。そのせいか、モデルをオブジェクトとして捉えがちである。しかし、エバンスは

知識豊富な設計
PCB の例で示したように、モデルによってとらえられる知識は、「名詞を見つける」ことに留まらない。ビジネスの活動やルールも、ドメインに含まれるエンティティと同じように、ドメインにとって中心的なのだ。(中略) エンティティや値を超えてその先に行こうとする、このような動きに伴った時こそ、知識のかみ砕きは力を発揮できる。

と述べている。そしてUMLやオブジェクト図に関しては

オブジェクトのふるまいとオブジェクトに対する制約は、それほど簡単に図示できない。

と述べている。

また、オブジェクト指向言語ではない例として、

オブジェクト指向言語ほど広く使用されるには至らなかったものの、Prolog言語もモデル駆動設計と自然に適合する。この場合、パラダイムにあたるものは論理で、モデルは論理学上のルール群とそれらが作用するファクトの集合となる。

と、Prolog言語を挙げている。

ただし、サービスに関しては、

ドメインの重要な操作でありながら、エンティティにも値オブジェクトにも自然な落ち着き場所を見つけることのできないものがある。その中には、本質的に活動や行動であって、物事でないものもあるが、我々のモデリングパラダイムはオブジェクトなので、とにかくオブジェクトに当てはめてみよう。(中略)サービスは節度を持って使用すべきで、エンティティと値オブジェクトからすべてのふるまいを奪ってはならない。

と、オブジェクトに固執する傾向も見られる。最後の方では、

ドメインにおける重要なプロセスや変換処理が、エンティティや値オブジェクトの自然な責務ではない場合、その操作は、サービスとして宣言される独立したインタフェースとしてモデルに追加すること。モデルの言語を用いてインタフェースを定義し、操作名が必ずユビキタス言語の一部になるようにすること。サービスには状態を持たせないこと。

とも述べているので、イベントやコマンドによるプロセスをサービスとして捉えることは可能である。

他にも、

それでも、永久にオブジェクトのパラダイムだけに限定しなければならないということではない。大勢で旅行すればいくぶん安全ではあるが、いつもそうすべきとは限らないということだ。

と述べており、将来的にはオブジェクト指向に固執しない可能性も示唆していた。