ドメイン駆動設計のモデリングハンズオンを開催して頂きました！
お疲れ様です。
外販グループの中嶋（@jnuank）です。
普段はbashでゴリゴリとトランザクションスクリプトを量産しています。
以前からドメイン駆動設計に興味があり、外部の勉強会やイベントに行ったりしていました。
先日DDD-Community-jpで開催されたDDD Talk MeetUp #2に参加した際、
主催の松岡(@little_hand_s)さんに、酔いに任せて「弊社でDDDセミナーをやって頂けませんか」とお願いをしたら、快くOKを頂けましたので、社内でDDD勉強会を開くに至りました。
本記事の構成について
本記事は、
- 外部講師の依頼から、社内勉強会を開くまでの準備運営について（節番号0.1〜0.5）
- モデリングハンズオンのレポート（節番号1〜8）
となっております
0.1.とりあえずはエンジニアたちに需要があるかを訊く
勢いでお願いしてOKを貰いましたが、まずは社内需要を訊こうと思い、Slackに投下。
いきなり#generalに投げるのは抵抗がありましたので、#learning_dddという私が勝手に作ったチャンネルで呼びかけました。
※余談ですが、弊社はSlack運用に関してかなりゆるく、個々人がある程度勝手にチャンネルが作れます。
良さげな反応だったので、とりあえずやる方向として、上司にご相談することにしました。
0.2.上司に相談をする
DDDといいますか、何かしらのプラクティスを広める際、よく耳にする経験談として、以下の話を聞きます。
- ドメイン駆動設計という単語を出さない（プラクティス名を出さない）
- 先に軽量DDDを始めて、じわじわと浸透させる
正直悩みましたが素直に「ドメイン駆動設計」と名前を出して、ご相談しました。
その辺りは理解のある上司だろうという見込みがあったのと、業務知識を大事にしているっていう方向性は知っていた為です。
このあたりは、松岡さんのブログから引用し、こういうのを始めたら、こんなメリットが期待できます、という簡単なスライドを作って上司に説明し、セミナーを開いて頂くことの了承を頂きました。
0.3.日程調整&会場用意
モデリングハンズオンをするにあたり、要件としては
- 【必須】各チーム、ホワイトボードがあること
- 【必須】登壇者用のプロジェクターがあること
- 【出来れば】ホワイトボードとかテーブルを行ったり来たりしても、お互いが邪魔にならないほどの広さ
という感じで、会場探し。
現在オフィスのレイアウト変更中につき、自社の会議室が使えなかったので、
これらの要件に見合う外部の会議室を借りました。
当日は5人1チームで、3つのチームが出来ましたが、
ホワイトボードは2台しか無かった為、
残りのチームには、下記の静電気に張り付くホワイトシートを用意しました。
0.4.告知
ここでまた、結構悩みました。
ドメイン駆動設計という名前を出して、皆さんに抵抗感覚えられるのはやだなーと思い、文面を考えるのに四苦八苦。
結局、タイトルをちょっとぼかしつつ、詳細内容にはDDDという単語を使うようにして落ち着きました。
最初に需要あるかどうか呼びかけた際に、大体10人くらいは集まるだろうって予測はついていたので、あとは他に興味ある人がいればいいなー、くらいの気持ちの告知でした。
0.5.当日の誘導
外部の会議室での開催のため、人の誘導、連絡が課題でした。
当日のセミナー用のチャンネルを作成し、場所のリンクとタイムスケジュールを貼って誘導。
※弊社、iOSDCや（中止になってしまいましたが）VueFesなどの、社員が複数参加するイベントでは、こんな感じで連絡用&ワイガヤ用のチャンネルを適宜作り、終了したらアーカイブみたいな使い方をよくします。
1. 勉強会開始
という感じで、ようやくセミナー開始です。
前半はスライドでDDDの概要のお話。
以下、個人的にメモしていたものを抜粋。
DDDが目指すものとは
DDDが目指すものは、ドメインモデリングによってソフトウェアの価値を高めることであり、
解決したい問題のモデリングがイケてなければ、その後がどんなに素晴らしい実装をしていても、度重なる仕様変更（≒事業成長）に耐えうるような良いソフトウェアにならない。
DDDにおけるモデルとは
問題解決のために、物事の特定の側面を抽象化したもの
現実には数多くの要素があるけど、すべてをソフトウェアに落とし込むことは不可能なので、解決したい問題に必要な要素だけ抜き出して抽象化したものが、モデルになる…という認識です。
良いモデルとはなにか
問題解決をすることができるモデル
悪いモデルになっていると、現実に即しておらず、運用でカバーすることが増えてくる。
（この説明に関して、参加者の何人かが頷いてたのが印象的でした）
良いモデルを作るためには
- ドメインに詳しい人から知識を得る
- 運用の知見をモデルにフィードバックして改善する
- 最初から良いモデルは出来ないので、改善し続けていく
本来であれば、モデリングと実装は交互に行ったり来たりしながら、改善していくそうですが、
今回のセミナーの後半では、モデリングをメインにハンズオンして頂きました。
2. いざ、モデリング
ハンズオンでは3チームに分かれ、以下の流れでモデリングをしていきました。
- テーマを決める
- ユースケースを書く
- スコープを決める
- ドメインモデルを書く
- 業務ルールをふきだしで書いていく
私のチームでは、いくつか候補を出した結果、
弊社の勤務ルールの中でユニークなルールである、One Day Outing（通称：ワンデー）についてのモデリングをしていきました。
週一で会社の外で仕事ができるルールなのですが、
弊社の人間であれば、みんな知っているので、モデリングがしやすそうだったのが選んだ理由です。
3. ユースケース図の表記は大事
早速、ワンデーに関わってくる登場人物（アクター）を出していき、その人達ができること（ユースケース）を書いていきます。
メンバー1：「ワンデーの申請を受ける人もいりますよね？」
メンバー2：「たしかに。上司が必要ですね」
ドメインエキスパート：「たしか、〇〇さんが社員全員、ワンデーを週何回取得してるかカウントしてるよ」
メンバー4：「じゃあ、〇〇さんもユーザとして書きます？」
メンバー5：「個人名じゃなくて、せめて部署名とかロール名で書いたほうが良いと思う。この場合はコーポレートグループじゃないですかね」
最初は「出勤を打刻」とか、「申請する」とか書いていましたが、
松岡さん：「ユースケースは、目的語を付けて、動詞にして書くといいですよー」
というアドバイスに従い、「〜を〜する」という形式にしていきました。
そうすると、誰が見ても、やることがハッキリわかってきます。
松岡さんのお話だと、「申請する」という言葉でユースケースを書くと、ワンデーを申請するのか、休暇を申請するのか、見てる人によって差異が出来て、認識がズレてくるそうです。
なので、ユースケースの文法は大事、とのこと。
4. ドメインモデル図を描く
これまでのユースケース図をスコープとして、ドメインモデルに落とし込んでいきます。
このあたり、ブレスト形式でやっていくので、結構楽しいです。
メンバー1：「ドメインオブジェクトって何があるんでしたっけ。【ワンデー】？」
メンバー2：「あとは、【申請】とか【従業員】とか」
メンバー3：「申請というよりは、【申請書】の方がわかりやすいかもです」
メンバー1：「申請、承認されてワンデーが出来るようになるなら、ワンデー自体に申請ステータスを持つのは？」
メンバー5：「ワンデーをすることと、申請をすることは別物として捉えた方が良い気がするから、分けたほうがいいと思う」
この辺、私個人の主観になりますが、ユースケース図を書くにあたって出てきた名詞から拾ってドメインオブジェクトを書いていくと、取っ掛かりとしてはいいのかなって思いました。
5. 業務ルールを書いていく
ある程度モデリングをしていき、だんだん業務ルールを書いていくフェーズに突入していきました。
メンバー3：「コーポの方がワンデーの回数をカウントする際、台風などの場合はカウントしない、は業務ルールですよね」
メンバー1：「こういうのって、どうやって非常事態的なワンデーと認識すればいいんですかね？ フラグを持っておけばいいんですかね？」
メンバー5：「【非常事態ワンデー】みたいなもの別で1個作って、そういうのはカウントしない、みたいな考え方でもいいかも」
ドメインエキスパート：「そういえば、Qiitaやブログ書くと、カウントの上限が増えるよ。あと足の骨折などで出社困難な場合などは特例でカウントされなかったり」
いろいろとルールが複雑になっていき、議論が広がっていきます。
後ろで見ていた松岡さんから、再びアドバイスを頂きます。
松岡さん：「ドメインモデル、業務ルールを書き出していくと、あれもこれもと色んな発見が出て、ユースケース図との乖離が生まれやすくなってきます。今回でいうと、ブログを書くと上限増えたり、などですかね」
松岡さん：「この場合、ユースケース図に書かれていないものはスコープ外とするのか、書き出してみて重要だったからユースケース図を追加修正をするかの、2パターンに分かれますねー」
どうするかチーム内で議論し、最終的には前者のユースケース図に描かれていないものは、スコープ外にする方針としました。
カウントの上限が上がるルールに関しては、開発の現場であれば、第二フェーズできっと実装されるはずです。
6.最後に共有
各チームのモデリングの内容や気づきを共有していきました。
共有している中で印象的だったのは、モデリングを始めてみると、あれも足りない、これも足りない、と何度も手戻りをしてモデルを描き直したという意見が多かったです。
この辺りは松岡さんも補足されていましたが、
実装に落とし込んでからの手戻りと比べると、わずか1時間ちょっとで何回も、リスク無く、手戻りが出来るモデリングはかなり強力なツールだと感じました。
7.モデリングを終えてみて
気づいた点
- 業務ルールが多いと、それらを押さえてシステムを作らないと、運用カバーになることが多い（メモ欄、備考欄みたいなもの作ったり）
- ホワイトボードに書くかどうか迷ったものは、とりあえず口に出して書いておく。
- それがあとでコーディングするときに役に立つ。
- ユースケース図とドメインモデル図の同期が取れなくなる（ルールがいっぱい出てきて、ユースケース以外のこともするようになってくる）場合は、スコープ外と判定するか、もしくはユースケース図に追加修正をする
- モデリングの最中、何度も手戻りをしていき、もどかしく感じたが、実装に落とし込んだあとの手戻りより、断然早い。
- あくまで業務をモデリングするので、ユニークIDとかシステマチックなことはいったん考えなくてもよさそう（考えておいてもいいとは思う）
今後モデリングをする上で気をつけたい点
- 普段所属するチームがバラバラなメンバー同士でやると、テーマ決めに悩む感じがあった。
- 普段は、同じチーム内でやると思うので、そこは気にしなくて良さそう。
- 実業務をモデリングしたチームもありましたが、現行システムからモデリングしていった為、◯◯ID、◯◯ステータス、◯◯オプションなど、システマチックな用語が結構飛び交っていた。
- もう少し業務寄りに捉えるようにしてもいいのかもしれない。
8.まとめ
実際に松岡さんに来て頂き、モデリングハンズオンを通して、こんな風にモデリングをしていけば良い、という具体的なイメージが得られました。
他のメンバーからも、モデリングが楽しかった、ハンズオンで実際にやると身につく、といった言葉もありました。
今回学んだモデリングの手法はプロジェクトでも活かせると思いますので、
試していきたいと思います。
