初めてのドメインモデリングから得た学び
この記事は、ドメイン駆動設計（ＤＤＤ） Advent Calendar 2021 22日目の記事です。
こんにちは、 @suzushin54 です。 Showcase Gig という会社で、O:der Table というモバイルオーダーのプロダクトを開発しています。
プロダクトや会社の紹介については、以下の記事をご覧いただければと思います。
現在の仕事で幸運にもドメインモデリングをする機会に恵まれました。これまで書籍を読んだりイベントに参加するなどして学習はしていたもの、初めての経験でした。
今回は会社のブログではないので、用語などを一般化した上で個人的な感想や反省、工夫を残していこうと思います。
環境
メンバー
6~7名の比較的よくあるプロダクトチームです。
ドメインエキスパートの招聘
PdMとManager, そしてカスタマーサポートの方にも参加してもらいました。この3名は日頃、同じチームとして活動しているわけではないのですが、スクラムのセレモニーなどには適宜参加してもらっています。業界やプロダクトに対する造詣が深く、まさにドメインエキスパートと言える存在です。
事前準備
はじめに、チーム内での認識を合わせることを目指しました。
今回、ドメイン駆動設計の経験者はいませんでしたが、DDD本を読んだことがあり知識はある人、増田さんの現場で役立つシステム設計の原則の社内輪読会に参加していた人、なんとなく聞いたことがある人、まったく知らない人、などなど、認識のレベルもバラバラでした。
とはいえ、これまた諸般の事情により、あまり時間がありません。今回はみんなで、松岡さんのドメイン駆動設計 モデリング/実装ガイドの輪読を行い、ドメインモデリングに入る最低限として以下の認識を合わせました。
※ 話としては前後しますが、プロジェクトの見積の都合でユースケースは既に一覧化していました。
ドメインモデリングの実施
ドメインモデリングはオンラインホワイトボードツールの miro で行いました。日頃からレトロスペクティブなどで使い慣れていたので、ここでの戸惑いはありませんでした。
一方で、実際にやってみてから気づくことが多々ありました。
やっぱりデータモデリングと混同する
これはあるあるかと思います。事前に違いとして、以下を確認していました。
- ドメインモデルはデータモデルとは異なる
- ドメインモデリングにおいて永続化は関心事ではない
- データモデルは永続化のためのものでありアプリケーションの都合である
- ドメインモデルはドメインの問題を解決するためのもの
しかし実際にクラス図のような図を前にすると、こういう属性があって、こういうデータができて...ということをエンジニアは考えがちなのだと実感しました。
従来のソフトウェア開発の経験から来る副作用のようなものですが、注意していれば気づくこともできるので、その都度修正していきました。
ドメインモデルの種類？
ここはまだあまり考えが纏まっていないのですが、モデルを洗い出していると静的なモデルと、そうではないモデルがあるように感じました。例えば、店舗モデルや商品モデルなど、実体があるものは前者のイメージで、注文モデルや会計モデルは後者です。前者の種類のモデルが状態を保つと若干の違和感があります（有効/無効などは当然あるのですが）。
また、元となるデータがあって、それが一時的に有効になっているようなモデルも表現に悩みました。例えば、焼肉が食べ放題のお店にいろんな料理の掲載された「メニュー」があるとします。この「メニュー」を元に120分間の食べ放題がスタートすると、「有効となったメニュー」のようなモデルが生まれたりするのですが、こういったところはまだ洗練されていない感覚があります。
貧血不可避なモデル
ひととおりモデルが出揃ったタイミングで振る舞いを書き出そうとしたのですが、結果としてここでは不要だったかもしれません。というのも、実際に書いてみた振る舞いも実装の段階になると「なんか違う」ということが多かったです。振る舞いとして書いたけどドメインイベントなのではないか。このモデルが振る舞いとして持つには集約を見直さなければならない、などなど。
また、これまで私たちが触っていたシステムはトランザクションスクリプトになっていることが多かったので、ドメインモデルの振る舞いをイメージするのは想像以上に難しかったです。実際に実装フェーズに入ってから出てきた振る舞いも多く、ある程度で切り上げて試行錯誤のサイクルを回す方が効率的でした。
Tips的なもの
付箋や吹き出しのルールを決めないと無秩序になる
意外にこれは大事だなと思いました。
あれこれ書き込んでもらうことは議論を促進させるためにも歓迎すべきことですが、各々が好きな色で「（単なる）メモ」、「疑問点」、「ドメインエキスパートの見解」、「現行システムの仕様」などを書き出すと、あとで整理するときに消して良いのか残すべきなのか、はたまた既に解決した疑問なのかなどがわかりづらくなりました。
あらかじめ凡例と雛形を用意しておくと書き込む心理的な障壁も下げられて良さそうです。
早めにドメインモデルを実装する
環境にも寄りますが、基本的にドメインモデル（ Entity, Value Object ) の実装はそれだけで完結できます。画面やEndpointを用意する必要がなく他の開発作業とは切り離して実行できるので、試行錯誤のサイクルを回しやすいと感じました。
おわりに
初めての経験でしたが、当たり前のことながら、やってみてわかることがたくさんありました。また実装に入った時に結構詰まってしまう感覚があったので、次回からはロバストネス図を描いてみることにしました。新しい学びがあったら、こちらも記録していきます。
