ドメインモデル作成の5つの注意点 第4回：もう迷わないシステム開発（3/4 ページ）

[今田忠博, 近藤正裕，ITmedia]

ドメインモデル作成の5つの注意点

　以下の点に注意しながらドメインモデルを作成します。

1.　クラス構造の洗練化：　後の設計やE-Rモデル作成を容易に行うために必要があれば構造の変換を行います。

• 例：　動的多重分類→状態クラス

• 例：　「一覧-明細」^（注1）構造への洗練（売上-売上明細など）

• 例：　「全体-部分」構造への洗練

2.　クラス間の関連に多重度を付ける

• 全ての関連端に多重度を付与する
• 関連の意図が分かりにくければ、関連端名（ロール名）を付けて関連の意味をより明確にする

3.　クラスに属性、操作を記述する

• 汎化-特化の関係にあれば、基底クラス・派生クラスのどちらに持つかを判断する
• 操作を持たせるクラスに無理がないかどうか、シーケンス図などでメッセージの流れを検証する
• 属性については、以下の情報を参考にする
  • 画面項目仕様
  • 既存の帳票などの文書
  • 既存のE-Rモデル

4.　ライフサイクル・永続化に関する分析

• 各クラスについてライフサイクル・永続化を検証する。特に永続対象ではないものについては、その旨をタグもしくはコメントで明記する。ロバストネス分析を行う場合は、その分析結果からもフィードバックを受けることができる。

5.　ユースケース-クラスCRUD分析

• この段階までで、ユースケースとクラスのCRUD分析を行って、ユースケースとドメインモデルの関係を精査することが望ましい。

• CRUDに全く関係しないユースケースがないか、マトリックスでCRUDの抜けはないかを確認する。CRUDに全く関係しないユースケースが発見された場合、ユースケースモデルの見直しを行う。CRUDの抜けがあった場合は、クラスのライフサイクルをもう一度分析し修正を行う。

ポイント

• 属性名は用語集と同期を取る
• 多重度に気を付ける
  • 多重度が0（関係を持たない）の可能性があるかどうか
  • 多重度の上限があるかどうか
• 「is-a-part-of」の関係になっていたら、集約で表す
  • 「A は B の一部である」

• 属性を付けるときの注意点
  • 「クラス名」＋の＋「属性名」として読んでみて違和感がないか
  • 派生クラスに共通の属性は、基底クラスに付けられないか
  • 以下の情報を参考にする
    • 画面仕様書
    • 対応するデータベースのテーブル（既存システムが存在する場合）
    • ユースケース記述の補足欄
• 操作を付けるときの注意点
  • 派生クラスに共通の操作は、基底クラスに付けられないか
  • 操作をどのクラスに付けるか迷ったときは、シーケンス図などでメッセージフローを書いてみて、冗長なやりとりがないかを確認する
• 属性が多すぎる、または関連が集中しているクラスがあるか
  • 責務（操作をグルーピングした概念）を複数持っていないか
    • クラスを分割できないか検討する

---

注1：　「一覧-明細」構造は『ストリームラインオブジェクトモデリング』でいう「コンポジットトランザクション-明細」パターンや、「特定品目-明細」パターンに当たります。