この記事はユースケース駆動開発実践ガイドメモのドメインモデリングについて記載します。
ドメインモデルの抽出
ドメインモデルを定義していくために、まずはサービスに対する要求を調べます。
ハンバーガーショップのデリバリーサービスを例に抽出します。
- ハンバーガーショップはWebベースを予定している。
- ハンバーガーショップは注文を受け付け、商品**を売ることができなければならない。
-
ユーザは商品一覧からショッピングカートに商品を追加、削除できなければならない。 -
ユーザは精算前にショッピングカートに商品がなければならない。 -
配送1時間前までなら、ユーザは注文をキャンセルできなければならない。 -
ユーザはクレジットカードで支払うことができなければならない。 -
商品のデータはマスターデータから取扱商品を取得してそれを商品一覧に組み込まなければならない。 -
商品はカテゴリ別に検索できなければならない。 - ハンバーガーショップはユーザの詳細情報(メールアドレス、パスワード、住所)を記録できるようにするために、ユーザはログイン時に顧客アカウントを作成できなければならない。
-
ユーザアカウントは編集できなければならない。 -
マスターデータは本部の商品部門が更新するため参照のみできる。
これらの要求からドメインモデルの情報源を抽出します。
カテゴリ、クレジットカード、顧客アカウント、商品、商品一覧、住所、精算、ショッピングカート、注文、取扱商品、配送、パスワード、本部の商品部門、マスターデータ、メールアドレス、ユーザ、ユーザアカウント
次にドメインモデルに落とし込む情報を抽出します。
アクターを判断して、この時点では不要な情報を削ります。
アクター：ユーザ、本部の商品部門
重複：顧客アカウント、ユーザアカウント→どちらを残すか決める。ここでは顧客アカウントを採用する。
ドメインオブジェクトとしては小さすぎる項目は削除：メールアドレス、パスワード、住所
抽出した結果が以下になります。
赤で記載している箇所は、抽出結果を元にステークホルダーと議論して新しく抽出されたと仮定してください。
ここでは集約関係(has-a関係)が表現されています。
この図はプロトタイプなので現時点では完全ではなく、最終的なクラス図とは異なっても問題ありません。
ここからまた議論して、下記のように洗練することもできます。
・清算はドメインモデルとして小さすぎるので削除
・クレジットカードと注文の間に支払方式を定義
・書籍一覧を汎化して、推奨品リストと検索結果を定義
ここでは汎化関係(is-a関係)が追加されました。
詳細化したドメインオブジェクトをサブクラス、一般化したドメインオブジェクトをスーパークラスと呼びます。
チームが納得いくまでこの作業を続けても大丈夫ですが、本書での目安は2時間とされてます。（多分足りない。。）
先ほども記載しましたが、この工程で完璧さを求める必要はありません。
まとめ
ドメインモデルを繰り返し定義することで、言葉の揺れや不足しているドメインオブジェクトを抽出するのに役にたちます。