DDD輪読会 II-5

関連を扱いやすくする3つの方法

1. 関連をたどる方向を強制する
2. 限定子を付加して多重度を減らす
3. 本質的でない関連を除去する

アメリカ大統領の例(1)

• 国と大統領：双方向の関係性

アメリカ(の大統領) ->
    ワシントン、ジェファーソン、モンロー

ワシントン -> アメリカ(の大統領)
ジェファーソン -> アメリカ(の大統領)
モンロー -> アメリカ(の大統領)

アメリカ大統領の例(2)

1. 関連をたどる方向を強制する

アメリカ(の大統領) -> ワシントン、ジェファーソン、モンロー

2. 限定子を付加して多重度を減らす

１７９０年のアメリカ(の大統領) -> ワシントン

オブジェクト指向言語における同一性

• 同一性の演算：Javaの==演算子など
  • メモリ上の位置の比較など
  • ドメインではほぼ無意味
    • 例）同日同口座同額の預入
  • 別の一意の識別子が必要
• 同じモノでもモデル上の表現が変わる
  • 例）座席予約：自由席と指定席

エンティティをモデル化する

• 同一性の定義：ドメイン理解が必要

  • パターン1：オブジェクトの属性
    • 例）新聞：名前、都市、発行日
  • パターン2：属性でキーが決まらない
    • UUIDなど自動生成
    • ID表示すべきか問題（ドメイン次第）
  • パターン3：システム境界を越える同一性
    • マイナンバー、社会保障番号etc

• 同一性の最終判断はユーザが行う

住所：エンティティか値オブジェクトか？

• 通販ドメインの顧客の住所：値オブジェクト
• 郵便ドメインの住所：エンティティ
• 電気会社のドメイン
  • サービス提供先：エンティティ
  • 住居の一属性：値オブジェクト

値オブジェクトの凝集度

• 概念的にまとまりとして表現すべき

// NG
顧客: { 名前, 都道府県, 市区町村, 番地 }

// OK
顧客 { 名前,
    住所 { 都道府県, 市区町村, 番地 }
}

値オブジェクトの設計

• 同一性がない＝どのインスタンスでも良い
  • 設計が自由、性能最適化が可能
  • 別のエンティティにコピーできる
  • 別のエンティティと共有できる
    • ゆえに不変であるべし
  • 性能のため1インスタンスを共有

// JavaのLong.javaの例
public static Long valueOf(long l) {
  final int offset = 128;
  if (l >= -128 && l <= 127) { // will cache
    return LongCache.cache[(int)l + offset];
  }
  return new Long(l);
}

値オブジェクトに可変性を認めるべきか？

• パフォーマンスを考慮して許可するケースも
  • 値が頻繁に変化する
  • オブジェクト生成・削除が高コスト
  • クラスタリングが妨げられる場合

値オブジェクトを含む関連を設計する

• モデル中の関連は数が少なく単純である方が良い
• 双方向の関連
  • エンティティの場合、保守が困難に
  • 値オブジェクトの場合、役に立たない（同一性がないので）

優れたサービスの3つの特徴

• 操作がドメインの概念に関係している
• ドメインモデルに基づくインターフェース定義
• 操作に状態がない（副作用はあってもよい）

サービスと隔離されたドメイン層

• サービスの3つのレイヤ
  • インフラ層の技術的サービス
  • アプリケーションサービス
  • ドメインサービス
• インフラ層の技術的サービス
  • 例）メール通知サービス
  • ビジネスに関する意味が一切ないはず
• アプリケーションサービス
  • ドメイン/技術的サービスを呼び出す
  • 入力を変換する
• ドメインサービス
  • 例）銀行業ドメインの資金振替サービス

粒度

• アプリケーションサービス：ドメインオブジェクトのふるまいが組み合わさる場所
  • ドメインサービスの粒度が細かいと、 ドメイン知識がここに流出する
  • 中くらいの粒度のサービスが吉

アジャイルモジュール

• 初期の誤ったモジュールが利用されがち
  • オブジェクトの結合度が高い
  • リファクタリングが困難
• ドメイン理解の深化に合わせ モジュールも変化すべき
  • 広範囲のコード変更、混乱を生む可能性
  • 歯を食いしばってリファクタリング（モジュール再構成）すべき

Javaのパッケージ利用例

• import my.package.*
  • モジュールの依存関係を伝える
  • リファクタリングが楽

フレームワーク駆動パッケージングの代償

• 例：J2EEの分割規約
  • オブジェクトが散らばってしまう
  • 複雑なフレームワークの理解で疲弊
• ドメインコードとそれ以外を分離するために パッケージを利用せよ
  • 参考：第４部 戦略的設計

パラダイムの混在

• 基本的にパラダイムを混在させないよう 努力すべき
• どの実装でも使える 単一のモデルを見つけよう
• 複数のパラダイムをまとめる効果的なツール ＝ユビキタス言語