ドメインモデルの設計

ドメインモデルの作り方

1 部分を作りながら全体を作っていく

• オブジェクト指向のアプローチとして、個々の部品を作り始め、それを組み合わせながら全体を構築していく
• ある部分に注目してその部分に必要なデータとそれを使ったロジックを一緒に考え、クラスとして設計していく。

2 部分と全体を行き来しながら作っていく 全体を俯瞰するツールとしては以下の2つがある。

• パッケージ図
  • 個々のクラスを隠蔽し、パッケージ単位で全体の構造を俯瞰する
  • パッケージ間の依存関係を表現する（オブジェクトを参照する方向に矢印でつなぐ）
  • パッケージ間の参照関係は業務フロー図を描きながら業務の流れの前後関係として確認する
• 業務フロー図
  • 業務の様々な活動を、時間軸に沿って図示したもの
  • 活動の主体ごと（顧客／販売／出荷／経理など）にレーンを並べて情報のやり取りを明らかにする

3 全体を俯瞰したら、重要な部分（＝間違いなく必要になる部分）からドメインオブジェクトを作っていく。

4 独立した部分を組み合わせて機能を実現する

ドメインオブジェクトの見つけ方

業務に必要なドメインオブジェクトを最初から網羅的に見つけることはできない。機能を組み立てていく中で、ドメインモデルに本来あるべきドメインオブジェクトが足りないことが明らかになっていく。不足しているドメインオブジェクトを見つけながら追加していくのが設計のやり方。

業務の関心事を分類する

業務の関心事をヒト／モノ／コトに分類する。

• ヒト：個人、企業など、業務の主体。
• モノ：商品、サービス、権利など、ヒトが業務を行うときの関心の対象。
• コト：予約、注文、出荷、キャンセルなど、業務活動で起こる事象。

コトに注目する

• それぞれの関心事の関係と重要性を明らかにするには、コトに注目して整理するのが効果的である
• コトに着目することで、次の関係が明らかになる
  • だれの何についての行為か（コトはヒトとモノの関係として出現する）
  • 前後関係（コトは時間軸に沿って明確な前後関係を持つ）

例：販売活動における一連のコト

• 受注
• 出荷
• 請求
• 入金

このうち、受注は他のコトと比べて以下の点で異なる。

• 発生源が外部のヒトである
• 将来に対する約束である

この売り手と買い手の間に成立した約束を適切に記録し、約束どおりに完了させることがアプリケーションの業務となる。
その際、以下の点で妥当性を検討する必要がある。

• 在庫はあるか
• 与信限度額を超えていないか
• 自社の販売方針に反していないか

これらを判定するためのデータとロジックからドメインオブジェクトを構築する。
さらに、約束相手や商品、時期などによって約束の内容やルール、妥当性が担保できなかった場合の手続きなどが異なるため、それらを実現するドメインオブジェクトを構築する。特に数量に関する業務ロジックは数量クラスにまとめることになる。

ドメインオブジェクトの設計パターン

ドメインオブジェクトの設計パターン

以下の4つのパターンがドメインオブジェクトの基本となる。

• 値オブジェクト：数値、日付、文字列等をラッピングしてロジックを整理する
• コレクションオブジェクト：配列やコレクションをラッピングしてロジックを整理する
• 区分オブジェクト：区分の定義と区分ごとのロジックを整理する
• enumの集合操作：状態遷移ルールなどをenumの集合として整理する

業務の関心事のパターン

業務ロジックは次の4つの関心事のパターンに分類できる。

• 口座パターン：現在の値を表現し、妥当性を管理する
  • 銀行の口座、在庫数量の管理、会計などで使うパターン
    • 関心の対象を「口座」として用意
    • 数値の増減の「予定」を記録する
    • 数値の増減の「実績」を記録する
    • 現在の口座の「残高」を記録する
• 期日パターン：約束の期日と判断を管理する
  • 約束を実行すべき期限を管理
  • その期限までに約束が実行されるかを管理
  • 期限切れの可能性について事前にアラートする
  • 期限切れとその程度を検知
• 方針パターン：様々なルールが複合する、複雑な業務ロジックを表現する
  • ルールの集合をもったコレクションを作成
  • ひとつひとつのルールについて、Ruleインターフェースを持ったオブジェクトを作る
  • ルールの集合に対していくつの条件が一致するかなどの判定を方針クラスに任せる
• 状態パターン：状態と、状態遷移のできる・できないを表現する