本記事は、 DDD-Community-Jp Advent Calendar 2020の3日目です。

はじめに

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

現在モデリング会では、RDRA、EventStorming、概念クラス図っぽいものを併用して描いています。

このとき、モデル駆動している実感を得られたので、書いていきたいと思います。

なお、私達が普段使っているモデリングツールはmiroです

お題のリポジトリ

架空の会議室ドメインのお題

RDRAとは　EventStormingとは

RDRA ＝　Relationship Driven Requirement Analysis
- アイコンのつながりによって、要求分析・要件定義をするフレームワークです。
  - RDRA2.0 ハンドブック
  - 【テレワーク下の要件定義（RDRA：ラドラ）】第１部「RDRAの考え方」
EventStorming
- ドメインで関心のあるイベントを時系列順に並べることにフォーカスしたモデリング手法です。

まずは失敗のお話

最初に、自分たちがどんな風にモデリングを始めていき、結果としてRDRAとEventStormingを使うことになったのかを話すために、失敗していったお話を書いていきます。

失敗1：実装とモデルが乖離したままになる

私達は最初に、ユースケースとクラス図に近いものを書いていきました。

これを元に実装を始めていったのですが、

「予約は15分単位であること」という事から、これを1つの単位とした概念がありそう……「コマ数」か
予約をする前に、予約を希望するという概念があるだろうから、「予約希望」というのがありそう
予約済みのものと表現するために、「予約済み」というのもあるだろう

といった感じで、実装するコードにこれらのクラスを追加していきました。

ここで私達が失敗したのは、実装上で生まれた概念をちゃんとモデルにフィードバックすることを怠っていました

結果的に数カ月後のふりかえりで、実装とモデルが合っていないよねという話をして、あらためて書き直してみたら、当時とだいぶ違ったモデルができあがっていました…。

失敗2：顧客から言われた通り（お題通り）に作ったら、思ったものと違ったシステムになった

新しく更新したモデルを見て、

「予約希望するって意味通りますか？　予約するは意味通るんですけどね」

といった指摘を頂き、自分たちが「予約」をモノとして見るのか、コトとして見ているのかの区別がうまく付いていないのがわかってきました。

コト、モノ、ヒトの整理をする上で、EventStormingが有効だと聞き、試してみることにしました。

最終的に以下のようなモデルとなりました。

これをやってチャット勢¹から以下のフィードバックをいくつか頂きましたが、微妙な結果に。

予約システムというより、ワークフローシステムっぽい
As-Isのレガシーなプロセスをそのまま表現しようとしている感じがある

これは受付の人に会議室予約したい、といった流れをイメージしていた為、「予約するなら、申請書が必要でしょ」「申請書を出した結果、借りられるのか埋まっていて借りられないかで、イベント変わるよね」といった話になってモデルに表した結果となりました。

EventStormingを初めてやったふりかえり

一度目のEventStormingを試したあと、ふりかえりをやってみました。

いろいろと出たのを簡単にまとめると、

EventStorming自体は有用である
- 集約を導き出すのにいい感じだった
ただし、前提として要求分析をしておかないと辛い
結果的にEventStormingでの時系列でイベントを見ていく手法を取ったことで、要件の組み立ての曖昧さがわかったことが発見できた
- 「どんなイベントを気にする必要があるんだっけ？」
- 「このイベント気にする？」など

といった風に、そもそもイベントに着目しようとすると、自分たちが想定しているお題の要件について理解度が足りてないということが判明してきました。

お題の要求の認識合わせの為に、RDRAを使用する

そもそもお題を文章でまとめたものから想像するモノが、みんなそれぞれ違いそうだね、というのが出てきました。

会議室予約のドメインに対して詳しくないから、「受付の人に申請書渡して予約する」みたいなのを勝手に想像をしてしまい、その結果がこのようなワークフローっぽいシステムが出来上がったと思います²

では、会議室の予約での困りごとを解決するために、どう要望を見つけて分析していけば良いのか。

ここでRDRAをやってみよう、という話になりました。

結果

意識したことは、主に以下の2点です。

あまり最初は個々の図に時間を掛けすぎない
- 時間を測って区切るようにする
とりあえず最初に全部の図を穴だらけでも良いので出していく

最終的に、時間を置きながら、3周くらいやってみて精度を高めていきました。

RDRAを踏まえた上で、EventStorming再チャレンジ

BigPicture

まずはBigPicutreレベル（イベントだけに注目した図）から描き出していきます。

ここでは以下の2点を意識していきました。

RDRAで出した要求モデルとビジネスコンテキスト図を傍に置いておき、EventStorming中に迷ったら、いつでも要求に立ち戻れるようにする
業務（下図でいう青いアイコン）の詳細の時系列の流れを、EventStormingで描き出していく

DesignLevel

BigPicureを元に、より実装に近いDesignLevelのEventStormingをしていきます³

RDRAをやる前と見比べてみます

結果

予約申請書とかいう、紙ベースの考え方が取っ払われていることがわかります。

また、RDRAで出した要求モデルの中に「予約したけど時間になっても予約者が来なくて使われなかったら、自動的にキャンセルできるようにしたい」と出ていたので、そちらもEventStormingに「ブッチされた」(ドタキャン的な意味)というイベントが追加されています。

ここで、1回目よりも格段に良くなったという実感が、私達の中で出てきました。

集約内部の境界の構造は別途モデリングする

ではここで実装か？　となったときに、まだ集約だけだと足りなかったので、
集約内部の境界でどんな属性があるのか、何と関連があるのかという構造的なモデリングが必要でした。
これは、概念モデル図っぽい感じで付箋で書き出しています。

自然とモデルに戻る　→　モデル駆動ができてきた

ここまでやっていて気づいたことが、実装をやっているときに頻繁にモデルに戻ることが増えてきました。

実装で詰まった時に「そういえばモデルってどうなってましたっけ？」問いかける、問いかけられる回数が増えた
実装が一段落した時に「じゃあモデルも更新しましょうか」となってきた
モデリングをしていて新しい概念が出てきた時に「空でもいいので、クラスだけ作っておきましょうか」と言うようになった

どうして回数が増えてきたのかと考えた時に、単純に私達の練度が上がったとか、チャット勢からの指摘や促しがあったとも言えますが、モデル間の整合性を保とうとする意識が上がったというのがありそうです。

ここでRDRAとEventStorming、その後の概念モデルが自分の中でどう接続されているのかを図示してみると、以下のような感じになってます。

RDRA自体が、要求分析のフレームワークの為、RDRAレイヤーの中にある各図の整合性は強く意識されています。
アクターの要望の背景にあるビジネスコンテキスト図の「業務」から、それをイベントに時系列に並べたものをEventStormingで表現し、その中から出てきた集約を概念図として表現するというつながりが実現できてきました。
その集約の境界内部を考える時の材料が、RDRAの情報モデルやロジック・ルールの元となる条件図になってきます。

このつながりと、異なる視点からのモデリング手法を複数取り入れたことによって、自分たちの中で視点の切り替えが上手くなったという実感が湧いてきました。

これは、実装やモデリングの過程で「あれ、この実装で合っていたっけ」「なんかよくわからない概念が生まれているけど、これは必要だっけ」と、違和感を覚えるセンサーが高まった状態になったと思っています。

こうなってくると、モデルを見るたびに新たな発見が生まれてくるので、モデルを気にする頻度が高まり、自然とモデルと実装を行き来するようになってきたのではないかと思っています。

RDRAとEventStormingの組合せが絶対の解ではない

ここまで書いていて、では「RDRAとEventStormingをやっておけば、うまくモデリングできるのか」と訊かれたら、絶対ではないと思います。

プロジェクトの種類だったり、チームの練度によって、ユースケースと概念モデルぐらいで充分だったりすれば、他の手法を取り入れることもあるでしょう。

モデルは、DDD本の定義から引用してくると、「ドメインにおける選択された側面を記述し、そのドメインに関連した問題を解決するのに使用できる抽象の体系」⁴です。

モデルで表現ができるのは、物事のある1つの側面と考えると、複数の視点（複数のモデリング手法）をもってドメインを捉えることは、より深い洞察ができるのではと思います。⁵

何かしらモデル間でつながりが取れる部分を見出すと、そこに整合性が取れない部分が発生した時に、「違和感」を感じ取れるようになるのだと思いました。（Aという図には、あるが、Bという図には出てこない用語とか。）

まとめ

ユースケース図と概念モデル図だけだと、自分たちでは最初足りなかった
- 概念の構造や関連に注視することが多く、その概念が生まれた背景や目的に意識が向きづらかった
異なる切り口のモデルを複数組み合わせることによって、視点の切り替えがしやすいし、そのモデルの整合性を取ろうと努めておくと、ズレたときに違和感が覚えやすいと感じた
モデルに戻るという鍛錬がそもそも足りてなかった
- これは常に意識する、1日の終わりとか何か節目のときにちゃんとふりかえる癖を付けておく必要がある

特に、モデルのつながりや整合性を意識してくるようになると、そこのズレを感じた時に違和感を覚えやすくなるのは、肌感ですが間違いなくあると思っています（もう少しこの辺りが言語化できるといいな）

モデリングと実装を音声で会話しているのとは別に、その様子を眺めてチャットでコメントをする人たちを、私達の中ではチャット勢と呼んでいます。チャット勢とか勉強会のスタイルについては、こちらの記事もご参照ください。 ↩
勉強会の為の、架空のお題だからというのもあると思います。とはいえ、たとえば受託とか立地的に離れていてドメインエキスパートと頻繁にコミュニケーションが取れないとか、ドメインエキスパートのたとえ話を鵜呑みにしてしまうとか、そういう時にも同じような事象は起きそうです ↩
EventStormingの本には間にProcessModelingというレベルがありますが、今回はそこまで小さな段階を経る必要はないとみんなで合意したので、飛ばしています ↩
エリック・エヴァンスのドメイン駆動設計 P.518 用語解説より ↩
そもそもRDRAは要求分析のための手法であり、EventStormingはドメインエキスパートが気にするイベントにフォーカスするので、より実装寄りです。各観点でそれぞれ別のツールを選んでつながりを意識したから、というのもありそうです ↩

複数のモデリング手法を取り入れることでモデル駆動が出来るようになってきた話