オブジェクト指向プログラミングにおける設計手法の一つ，ドメイン駆動設計の入門書． 解決したい課題の環境＝Domainとそれを構成する要素＝Domain objectを基本単位として，アプリケーションをボトムアップ的に組み上げていく． キモは，Domain objectが，どういった性質やルールをもつのかという知識，つまり抽象度の高い概念を集約し，その他の抽象度の低い実装上のあれこれとは切り分ける点． 提唱されたのは2003年頃らしい（p.14）． 本の構成としては，ユーザー管理アプリケーションを題材として，Domain objectから出発し，デザインパターンを道具としてボトムアップに改善していく． ドメイン駆動開発設計の雰囲気を知るのに向いていて，本格的に知りたい場合には物足りない程度．
個人的には，オブジェクト指向のあれこれを再認識しつつ，ドメイン駆動開発の雰囲気を知れる一冊だった． 結城浩さんのデザインパターン入門に出てきたもの，出てこなかったものもあり．
基本要素：Domain object, Domain Service, Repository
value object
性質 1. 不変（メモリに書き込まれた値は変更されることはない） 2. 交換可能（メモリの参照先を変えることで値が変わる） 3. 等価性によって比較（属性の値で比較）
作成基準 1. ルールが存在しているか？（名前，なら性＋名，など） 2. 単体で扱いたいか？
Entity
性質 1. 可変 2. 同じ属性であっても区別される（固有IDのイメージ） 3. 同一性により区別される
作成基準 * ライフサイクルがある（例＝ユーザー）
Domain Service
- 「ドメインオブジェクト」を扱うサービス．アプリケーション層と区別
作成基準 * 迷いが生じたらまずはEntityかvalue object．なるべく利用しない
Repository
- 保存・復元を担うbridge役
- SQL, InMemoryなどを柔軟に切り替え
（なんとなく）分かったこと
- domain objectを外部から操作されたくなければ，Application Serviceのみ公開．objectを値のみを持たせたData Transfer Objectを返すなど．
- タスク依頼時はcommand objectを渡すことで，値の組み合わせ事にmethodを分割せず，単一メソッドの中で場合分け，集約できる
- エラーは処理続行OK，例外は処理を止める
- 凝縮度の計算方法Lack Of Cohesion in Methods：全ての属性がメソッドで使われてる状態が最もよく，メソッドごとに属性が独立なら分けることを検討する．
- 依存関係逆転の原則（Dependency Inversion Principle）
- 上位レベルのモジュールは下位レベルのモジュールに依存してはならない．どちらのモジュールも抽象に依存すべきである
- 抽象は，実装の詳細に依存してはならない．実装の詳細が抽象に依存するべきである →できていないなぁ．．．
- ファクトリの検討：コンストラクタ内で他オブジェクトを生成する
- アーキテクチャ：レイヤード（上から下へ）, ヘキサゴナル（adapterの用意），クリーン（ヘキサゴナル＋Port実装の具体化あり）
- 実務の人々との対話・ユビキタス言語：共通語・共通認識，が結局は重要
分かっていないこと
- デメテルの法則 メソッドを呼び出すオブジェクト：オブジェクト自身，引数として渡されたオブジェクト，インスタンス変数，直接インスタンス化したオブジェクト → 飲み込み切れてない
- transaction：lockとの違い不明
- singleton vs static：ポリフォーリズム（継承元のクラスに継承先クラスが代入できる？）の恩恵を受けたければsingleton
使用したことがない
- Optional
型：基本はクラスTだが，nullを含む可能性があることを明示 - 遅延実行（IEnumerable型？)：オブジェクトを実体化させるべき時点まで処理しない
