【10分で分かる】ドメインモデリングの進め方

本記事はダグ・ローゼンバーグ著のユースケース駆動開発実践ガイドや、ネット上の人気記事を参考に書かせていただいています。

導入

ドメインモデリングとは？

• プロジェクト用語集、プロジェクト内で利用される用語をまとめた「生きるている」辞書
• 初期段階で完璧なものを作ることは不可能で、繰り返し議論し固めていく

何故ドメインモデリングが重要なのか？

• プロジェクトメンバー全員に明確な用語で問題領域を確実に理解させることができる
• プロジェクトのスコープを定義し、ユースケース作成の基盤とも成る

　作成のためのガイドライン

ユースケース駆動開発実践ガイドで紹介されている、ドメインモデル作成のためのガイドラインを紹介します

作成のためのガイドライン

1. 現実世界のオブジェクトに少テインを合わせなさい
   1. ソフトウェアは変化しやすいが現実は変化しにくいので、より現実世界を意識することでモデルの要求の変化に強くする
2. 汎化・集約関係を使いなさい
3. 最初のドメインモデリングにかける時間は2時間に限定しなさい
   1. ドメインモデルとはそもそも不完全なもので、何が足りないかを「ユースケース図」「ロバストネス図」を作成するプロセスこそに意味がある
4. 問題領域の主要な概念を中心にクラスを構成しなさい
5. ドメインモデリングとデータモデルを勘違いしてはいけません
   1. 似てる結果になることもあるが同じではない
   2. 良いクラスは比較的小さくまとまっているが、テーブルはその限りではない
6. オブジェクトとデータベースのテーブルとを混同してはいけません
7. ドメインモデルをプロジェクトの用語集として使いなさい
   1. 似た用語は必ず1つにまとめること。話す人によって意味が変わる用語も存在してはいけない。
8. ユースケースを書く前にドメインモデルを書きなさい
9. 最終的なクラス図が、ドメインモデルと正確に合致することを期待してはいけません
   1. クラス図は詳細に仕上げていくが、ドメインモデルは意図的にシンプルに仕上げること
10. ドメインモデルには画面やその他のGUI固有の部品クラスを配置してはいけません
    1. 純粋にドメインモデルの問題領域の表現に注力すること 　

実践

1. 要求定義

ドメインモデル構築時にドメインクラスの抽出源として利用する情報源には、高い抽象度を持った要求が含まれています。
これらは「システムは〜しなければならない」「システムは〜すべきではない」という形式で記述されることが多いです。

では今回モデリングするシステムの要求を見ていきましょう。

システム要求

1. ユーザーは精算前に、オンラインショッピングカートに書籍を加えることができ なければなりません。
2. 同じように、ユーザーはショッピングカートから品目を取り出すことができなければなりません。
3. ユーザーは、あとで購入するつもりの書籍に対する購入予定リストを利用できなければなりません。 1.配送前であれば、ユーザーは注文をキャンセルすることができなければなりません。
4. ユーザーはクレジットカードや発注書で支払うことができなければなりません。 1.ユーザーは書籍を返品できなければなりません。
5. システムが(名前、住所、クレジットカードといった)ユーザーの詳細情報を記録できるようにするため、ユーザーはログイン時に顧客アカウントを作成できなければなりません。
6. ユーザーはさまざまな検索方法(タイトル、著者、キーワード、カテゴリーなど)で書籍を検索し、そこから書籍詳細を見ることができなければなりません。
7. ユーザーは自分の好きな書籍に、レビューを投稿することができなければなりません。レビューコメントは書籍詳細に表示されなければなりません。レビューは顧客評価(1~5)を含み、> 書籍一覧で書籍のタイトルとともに表示されなければなりません。
8. スタッフは編集者レビューを投稿することができなければなりません。また、それは書籍詳細ページに表示されなければなりません。

2. 用語抽出・整理

これらの要求から、強調された名刺や名詞句をリストにしていきます。

名刺・名詞句リスト

アカウントリスト
クレジットカード
購入予定リスト
顧客
顧客アカウント
顧客評価
書籍
書籍一覧
書籍詳細
書籍レビュー
ショッピングカート
精算
タイトル
注文
著者
発注書
販売者
品目
編集者レビュー
ミニカタログ
ユーザーアカウント
レビューコメント

続いて抽出した名詞を整理していきます。

名刺・名詞句リスト整理

• 「顧客」「顧客アカウント」は同じように思えるかもしれないが、実際は異なる
  • 顧客 : アクター
  • 顧客アカウント : DBに格納されるエンティティ
• 「ユーザーアカウント」「顧客アカウント」は同じなので、今回はより明示的な「顧客アカウント」のみ使用する
• 「書籍レビュー」「レビューコメント」は同じなので、「書籍レビュー」を使用
• 「書籍一覧」は抽象度が高い名詞である。不明な点はドメインエキスパートによく尋ねる

などなど。。

3. モデリング

整理した名詞リストを元に、1回目のモデル図を書いていきます。

4. 集約関係(has-a)を記述

上記では既にhas-aの関係を記述してありますが、全てが正しい状態ではありません。
正しいかどうかを判断する方法の１つに「◯が△を持っている」と声に出して読み上げる、という方法があります。
「注文」は「精算」を「持っている」かどうか、を考えると、イマイチイメージしづらいことに気付くでしょう。
自然な関係を考えると、「顧客アカウント」が「注文履歴」を持っていて、「注文履歴」が「注文」を持っている、という関係に落ち着くでしょう。
また、「精算」は名詞ではなく動詞に近いので取り除きます。
また「著者」はクラスとしては小さすぎであり、「書籍」の属性に過ぎないので取り除きます。

5. 汎化関係(is-a)を記述

続いて汎化関係(is-a)について考えます。
まず「書籍一覧」について考えます。
「書籍一覧」についてユーザーのニーズを深堀っていくと、「購入予定リスト」の他に、「関連書籍」「推奨品リスト」「検索結果」などの言葉が存在することが分かりました。
汎化の関係を判断する方法の１つに「◯は△です」と言葉に出す、という方法があります。

• 「購入予定リスト」は「書籍一覧」です。
• 「関連書籍」は「書籍一覧」です。
• 「推奨品リスト」は「書籍一覧」です。
• 「検索結果」は「書籍一覧」です。

この文章がしっくり来れば、それは汎化の関係と言えます。

6. 上記を反映する

上記を反映し、一部修正を加えたのが下記になります
これを元に実装やユースケース分析を進めていくわけですが、次以降のフェーズに取り組んでいる過程不自然な点が明らかになっていくと思われます。
そうした場合はまたドメインモデル図を修正し、反復的に改良していく、というサイクルを繰り返していきます。

引用

ユースケース駆動開発実践ガイド
ドメインモデリングの始め方