Edited at

ユースケース駆動開発 - ドメインモデリング編

この記事はユースケース駆動開発実践ガイドメモのドメインモデリングについて記載します。


ドメインモデルを定義する意味

ドメインモデルを繰り返し定義することで、言葉の揺れや不足しているドメインオブジェクトを抽出するのに役にたちます。


はじめに

ドメインモデルを定義していくために、まずはサービスに対する要求を調べます。

ハンバーガーショップのデリバリーサービスを題材にします。


  1. ハンバーガーショップはWebベースを予定している。

  2. ハンバーガーショップは注文を受け付け、商品**を売ることができなければならない。


  3. ユーザ商品一覧からショッピングカート商品を追加、削除できなければならない。


  4. ユーザ精算前にショッピングカート商品がなければならない。


  5. 配送1時間前までなら、ユーザ注文キャンセルできなければならない。


  6. ユーザクレジットカードで支払うことができなければならない。


  7. 商品のデータはマスターデータから取扱商品を取得してそれを商品一覧に組み込まなければならない。


  8. 商品カテゴリ別に検索できなければならない。

  9. ハンバーガーショップはユーザの詳細情報(メールアドレス、パスワード、住所)を記録できるようにするために、ユーザはログイン時に顧客アカウントを作成できなければならない。


  10. ユーザアカウントは編集できなければならない。


  11. マスターデータ本部の商品部門が更新するため参照のみできる。


ドメインモデルの抽出

題材からドメインモデルの情報源を抽出します。

カテゴリ、クレジットカード、顧客アカウント、商品、商品一覧、住所、精算、ショッピングカート、注文、取扱商品、配送、パスワード、本部の商品部門、マスターデータ、メールアドレス、ユーザ、ユーザアカウント

次にドメインモデルに落とし込む情報を抽出します。

アクターを判断して、この時点では不要な情報を削ります。

アクター

ユーザ、本部の商品部門

重複

顧客アカウント、ユーザアカウントのどちらを残すか決める。

ドメインオブジェクトの整理

メールアドレス、パスワード、住所は小さすぎる項目のため削除

抽出した結果が以下になります。

赤で記載している箇所は、抽出結果を元にステークホルダーと議論して新しく抽出されたと仮定してください。

Untitled.png

ここでは集約関係(has-a関係)が表現されています。

この図はプロトタイプなので現時点では完全ではなく、最終的なクラス図とは異なっても問題ありません。

ここからまた議論して、下記のように洗練することもできます。

清算はドメインモデルとして小さすぎるので削除

クレジットカード注文の間に支払方式を定義

書籍一覧を汎化して、推奨品リスト検索結果を定義

Untitled (2).png

ここでは汎化関係(is-a関係)が追加されました。

詳細化したドメインオブジェクトをサブクラス、一般化したドメインオブジェクトをスーパークラスと呼びます。

チームが納得いくまでこの作業を続けても大丈夫ですが、本書での目安は2時間とされてます。(多分足りない。。)

先ほども記載しましたが、この工程で完璧さを求める必要はありません。


まとめ

ドメインモデルを繰り返し定義することで、言葉の揺れや不足しているドメインオブジェクトを抽出するのに役にたちます。