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