前回のふりかえり
- 第6章(リポジトリ)の主旨
第7章 言語を使用する：応用例
※ 2部で登場した技術の実践編のような章 貨物輸送システムを例に、第2部で紹介したパターンが問題をどう解決するのか見ていく
ドメインを隔離する
- レイヤー化アーキテクチャを適用してドメイン層を区切る
- 貨物輸送システムから、アプリケーション機能を識別してアプリケーション層クラスに割り当てる。 ※ アプリケーションクラスは調停役。調停役は自分で出した質問の答えを自分で算出しないことが特徴(それはドメインクラスの役割)
エンティティと値オブジェクトを区別する
- 各オブジェクトを順に検討しながら、 追跡すべき同一性 や、基本的な値 を探す。
- 同一性が必要となるものは エンティティ
- 同一性が必要なく、属性(名前・タイムスタンプ)などを持っているものは 値オブジェクト
ドメインの関連を設計する
- 現実のオブジェクトは様々なオブジェクトとの関連を持っているが、モデルとして必要な関連だけに絞る
- 関連を辿れる方向は、モデルとして必要でなければ一方向に制限する
集約の境界を引く
- 独自の同一性を持つエンティティは、自分の集約を持って、そのルートエンティティとなる
- エンティティであっても、他のエンティティと同一性を共有するものは自分の集約を持たない(どこかの集約に組み込まれる)
リポジトリを選択する
- 集約の外部から参照できるのは集約ルートのみ
オブジェクトを生成する
- プリミティブなコンストラクタで生成したいのは下記の様なオブジェクト
- 不変条件を満たしているオブジェクト(値オブジェクト？)
- 同一性が侵されていないエンティティ
- それ以外のオブジェクトはファクトリを利用することになる
モジュールについて
- 凝集度の高い概念(顧客・輸送など)を探し、その概念を元にモジュールを作成する
新機能の導入について
- 外部システムと通信する必要が出てきたときは、クラスを作成して、自分たちのモデルと外部システム間の言語の変換を担当させる。
- 自分たちのアプリケーションが必要とする機能だけをこちらに見せ、それらの機能をドメインモデルの観点から再び抽象化する。
→ 腐敗防止層というらしい。詳しくは14章
- モデルをより表現力豊かにするために、 エンタープライズセグメント と呼ばれるクラスを使うこともできる(詳しくは11章？)
思ったこと・気になったこと
- 第2部で出てきたパターンをどんな流れで適用していくのかはわかった。
- 最後に出てきたエンタープライズセグメントは正直全然よくわかっていない...11章で詳しく説明されるのか？
