Event Stormingでの集約の導き出し方

Last updated at 2020-12-01Posted at 2020-11-30

はじめに

DDD-Community-JP(以下、DDDCJ)内では架空の会議室予約のドメインを考え、C#で実装するモデリング会を隔週ペースで行っています。

そこで実施したEvent Stormingというモデリング手法が、集約を探すのに便利そうだっていう意見があったので、そのお話を書いていこうと思います。

Alberto Brandolini 氏が提唱しているモデリング手法です
- ぱっと見た感じ、ユーザーストーリーマッピングに近い感じですが、ユーザの行動にフォーカスするのではなく、ドメインエキスパートが気にするイベント（＝ドメインイベント）にフォーカスし、時系列に並べていきます。¹

実際のやり方は、モデリング会ではどんな感じにやったのかは、以下の @98lerr さんのの記事をご参照ください。
- EventStormingをやってみた話 - Qiita

Event Stormingは、「ドメインエキスパートが気にしているイベントはどんなものがあるのか？」が起点となっていますが、これは集約を探していくのにも重宝します。

始めはワークショップの中で、イベントとそれに対応するコマンドを出していくことになります。
たとえば会議室の予約で考えたときに、「会議室を予約する」というコマンドに対して、「会議室を予約した」というイベントが起きます。

ではこのコマンドを受け取り、「会議室を予約した」というイベントを発行する集約はなんだろうと考えた時に、「予約」という集約が出てきそうです。²

予約の変更や、予約のキャンセルも考えるとこんな感じになりそうです。

このときに、予約集約が持つべき振る舞いがコマンドから特定できてきます。

予約集約が自身で予約したり、キャンセルしたりするのに怪しい部分を感じます。
もしかしたら予約という名前ではないのかもしれません。

こういった違和感を覚えるのも、前後にコマンドとイベントがあるからだと思います。
そして、そのイベントはユーザが気にしている出来事から出てきているはずなので、そちらを拠り所として集約を考えていくことができます。

ここからは、Event Stormingでの正規のやり方から外れていきますが、
コマンドとイベントでの間にあるルールとロジックを考えておくと良いのではないか、という案です。

会議室を予約する時には、なんでもかんでも予約できるとは限らないはずです。
予約したいところが既に使用中だったりするでしょうし、1年先を予約されても困るので範囲を限定したいとか、そもそも使っていい時間帯が決まっているとか。

そういったビジネスルールやロジックを、集約の付箋の近くに置いておくと、いざ集約の境界内をモデリングするときの材料として考えることができそうです。

もちろん全てが集約のロジックになるかと考えると違うでしょうが、
少なくとも関連するものとして近くに置いておくと、ドメインエキスパートと一緒に議論するときにでも、わかりやすいのではないか、といった仮説です。³

Event Stormingはあくまでイベントに着目し、その前後にどんなコマンドがあり、外部システム、アクター、リードモデルが出てくるかを、時系列に表したものです。
集約の境界内でどんな属性（値オブジェクトもしくは子エンティティ）を持たせるかは、別途考えていかなければいけないと思っています。

実際に考えるときは、予約の集約の内部にどんなものがあるかを付箋に書き出してみました。

Event Stormingで出したボードが、関心事が変わってくるのであれば、線を引いて境界づけられたコンテキストを分けていけたりします。

会議室の予約で言うと、会議室予約と、会議室を実際に使用するのは、別のコンテキストとして区切ってみました。

Event Stormingは、イベントやコマンド、集約やリードモデルといった単語から想像できると思いますが、イベントソーシングやCQRSなどを半ば前提としたモデリング手法だと思います。

ただ、そういった実装にする予定ではなくても、Event Stormingは集約を探求するのにかなり良い手法だと感じています。

ドメインイベントとは、実践ドメイン駆動設計の8章で紹介されています。定義としては「ドメインエキスパートが気にかける、何らかの出来事」となっています。 ↩
予約集約が予約するのって変では？　というツッコミもあると思います。予約したときに問題なく予約が生成できれば（不変条件が満たされていれば）、問題なく予約が生成ができたら、完了イベントを発行するといったのを今は想定しています ↩
実際ビジネスサイドと話をする際には、例に出しているDesign LevelのEvent Stormingではなく、もっと抽象度の高いBig Picture、Process Modelingでやるべき話なのかもしれません ↩