エリック・エヴァンスのドメイン駆動設計

http://amzn.asia/d/28Bh6v2

知識をかみ砕く

• ドメインエキスパートとのコミュニケーションが大切
• 本当は何を知りたいのかを聞く
  • 内部的に行っているがユーザーが知る必要のない機能は省く
• モデルはドメインエキスパート、モデル設計者で共有言語（ユビキタス言語）にする
  • ビジネス側と開発側で同じことを意味しているのに別の言葉になると説明で混乱を招く
• 継続的学習を行う
  • チームメンバ、開発者、ドメインエキスパートでフィードバックループを行う
• 隠された概念を引き出す

モデルと実装を結びつける

• モデル駆動開発
  • 分析も出ると設計をわけず、両方の目的に使える単一のモデルを探し出す
  • 設計はドメインモデルに紐づける
  • ユーデーインターフェースに出てくる形で名前を付ける

ドメインを隔離する

• レイヤー化アーキテクチャ
  • UI：GUIの描画、イベントの解釈など。ViewやController
  • アプリケーション：やるべき作業を調整するだけ。サービス
  • ドメイン（モデル）：ビジネスルール。ここがメイン
  • インストラクチャ：一般的な技術的機能。メッセージ送信、ORマッパーなど

ソフトウェアで表現されたモデル

• エンティティ：参照オブジェクト：連続性と同一性によって定義される
  • 全く同じ要素のものが存在していても、別々に作成されたら別物である
  • ふるまいが明確で予測可能になるように、連続性を確立あっせる
  • もっとも本質的な特徴にまでそぎ落とす
• 値オブジェクト：同一性を与えないもの。値にのみ意味があるモノ。
  • string a = 'a' と string b = 'a' の時、 a == b
• サービス：モデルにおいて独立したインターフェースとして提供される操作
  • エンティティや値オブジェクトのようには状態をカプセル化しない
• 関連するオブジェクトの集まりを集約化する
  • データを変更するための単位として扱う
  • ルートは集約に含まれている特定の1エンティティ
  • 外部のオブジェクトが参照を保持してよいのはルートのみ
• オブジェクトや集約全体を生成するのが複雑になったらファクトリを使う
  • オブジェクトの使い方ではなく作り方をカプセル化