DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。
そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。
(本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。)
DDDの目的
DDDの目的から確認しましょう。
DDDの目的は2つ。
①機能性を高めること
これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。
そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。
②保守性を高めること
これは、長期間開発しても機能拡張が容易でありつづける、つまり、「技術的負債でどんどん開発速度が低下する」を避けることです。
このために、モデルをそのまま表現する実装と、 エンティティ、リポジトリなどの実装パターンの適用などを行います。
DDDの特徴は、「ドメインモデル」を使って両方のアプローチがリンクすること、片方ずつでも効果が出ますが、両方使うと大きな相乗効果が出ることです。
モデリングってどうやるの？
モデリング手法は、「DDDだったらこれ」と一つに決まっている方法はありません。
この記事で紹介するモデリング手法は、「sudoモデリング」という名称のものです。
これは4つのモデリング手法の頭文字(後述)で、さまざまなモデリング手法から、DDDで実装に落とし込むための最小限のラインナップとして 筆者が抽出したものです。
筆者が働いているログラスでは、この方法で1年半以上モデリングを行い大きな成果が出ています。また、複数の企業でモデリング導入支援を行い、導入ハードルが低く効果を出しやすいというフィードバックを多くいただいています。
sudoモデリングとは
4つのモデル図を作成します。
- システム関連図 (s)
- ユースケース図 (u)
- ドメインモデル図 (d)
- オブジェクト図 (o)
この4つは、大体の場合において、「最低限この4つは書くとよい」というラインナップです。
そのため、必要に応じて別の種類の図も追加で作成することはあります。状態遷移図、ER図などは合わせて作ることが多いですが、そこは適宜判断いただければと思います。
sudoモデリングのサンプル
モデリングの題材は、人事などの採用担当者が企業への応募者を管理する、採用管理システムとします。
①システム関連図
開発するシステムと、関わりのあるアクターや外部システムとの関連を示す図です。
具体例
簡単な図のようですが、この図を整理するためには次のような疑問に対して答えを出す必要があります。
・これは誰が使うシステムなのか？
・開発するシステムで応募を直接受け付けるのか？
②ユースケース図
ユーザーの要求に対するシステムの振る舞いを定義する図です。
具体例
このシステムのユースケースとしては多くのものが考えられますが、まずはこのタイミングでのドメインモデル図作成の対象とするものを絞り込みます。
③ドメインモデル図 & オブジェクト図
ドメインモデル図は、簡易化したクラス図のようなもので、次のようなルールで記述します。
- オブジェクトの代表的な属性を書くが、メソッドは書かなくてよい
- 「ルール/制約(ドメイン知識)」を吹き出しに書き出す
- オブジェクト同士の関連を示す
- 多重度を定義する
- 集約の範囲を定義する
- 日本語と英語の対訳を定義する
オブジェクト図は、ドメインモデルの具体例を記した図です。
どちらから作っても良いですが、具体例のオブジェクト図から作る方がやりやすいことがあります。
モデル図の例
オブジェクト図(具体例)
ドメインモデル図(抽象化物)
ドメイン知識(①)
最終的にエンティティ/値オブジェクトとなるオブジェクトと、それに関わるルール/制約(=ドメイン知識) を記載します。
検討メモ(②)
たとえば、「選考ステータスってどんなのがある？」といった疑問が生じたら、その場で議論して決定した内容を記載します。モデリング時に発生した未決事項や今後の展開に関しては、②③のようにメモしておきましょう。
ドメインモデル図をもとに発見を誘発し、関係者の認識を残しておくために必要なものは積極的に記述しましょう。
多重度(④)
「採用選考から採用ポジションを紐づけることは必須な
のか？」といったことは、ルール/制約として大切な意思決定となります。
集約の範囲(⑤)
オブジェクト、ルール/制約の記述がある程度できてきたら、集約の範囲を決定します。
リポジトリは集約に対して1 つ作るので、集約の範囲が決まるとエンティティ、値オブジェクト、リポジトリがどういう形で実装されるかが決まります。
ただし、集約の範囲の良し悪しは実装してみないとわからないことが多いです。ここで一旦決定したあと、実装して問題があればいつでもドメインモデル図に戻って更新します。
日本語名の対訳としての英語名(⑥)
ここで英語名を決めると、この後のエンドポイント名、テーブル名、クラス名などで使われる名称が表記揺れするのを防げます。
モデリングを行う上で重要なこと
以上の4つのモデル図を作ることで、この後のコーディングに繋いでいくことができます。
ここで重要なことは、モデリングの良し悪しはこの段階ではわからないということです。モデリングは、あくまで抽象的な解決策の仮説です。仮説は検証する必要があります。
この仮説を検証するには、コードを書き、実際に作ったものを動かしてみて・・・というフィードバックサイクルを回す必要があります。そのため、最初のモデリングはあくまでバージョン1のα版であるという認識をして、ある程度のところでまずはコーディングに進むことをおすすめします。
もっと色々知りたくなったら
本記事の内容はDDDに関する解説書「ドメイン駆動設計FAQ＆サンプルコード」の「2.1 モデリング方法と具体的サンプル」からモデリングに関する部分を一部抜粋したものです。 本書においては、このモデルをコードにで表現するところまでを具体的なサンプルコードと合わせて解説してします。
本書は重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。
また、YouTube動画による解説もあります。
プレイリスト10分でわかるDDDシリーズには他のコンテンツもあります。
その他の筆者執筆書籍
初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍です。 迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。
現場での導入で困ったら
DDDを導入しようとすると結構試行錯誤に時間がかかります。
現場で導入してすぐに効果を発揮したい！！という方向けに、基礎解説とライブモデリング/コーディングを行う勉強会の開催や、設計相談を受付ております。
事例紹介もあるのでご関心あれば覗いてみてください。開催形式は柔軟に対応できるのでお気軽にご相談ください。
