DDD本をとりあえず読んだので，気になった部分をまとめます．
↓5章までは以下にまとめてます．
http://blog.hatena.ne.jp/MitubaEX/mitubaex.hatenablog.com/edit?entry=17391345971618128236 mitubaex.hatenablog.com
6章
集約
エンティティと値オブジェクトをまとめたもの． 集約にはルートエンティティがあり，このルートのみを外部のオブジェクトは参照できる．
本で挙げられてた例では，自動車がルートエンティティでその下に車輪，タイヤ，位置が保持されている． これにより，自動車の下にある車輪は外部のオブジェクトから参照されることが無く，集約内部での不変条件を満たせる． この不変条件というのは，自動車だと前のタイヤは二つで後ろのタイヤは二つといった絶対変わらない条件のことを指す． 後ろのタイヤを勝手に誰かに変えられると困るかもしれない．
ファクトリ
オブジェクトを作成，再構成する役割を持つオブジェクト． 複雑な処理をカプセル化できたりする． 基本的な役割は，集約を作成して集約のルートを渡す．
ファクトリは，エンティティを再構成する時，識別子を新たに作ってはいけない． だからファクトリメソッドの引数には識別子を入れる． オブジェクトの再構成をする場合は，DBなどですでに値が書き換わっているかなど確認することが多いらしい．
リポジトリ
クライアント，DB間のインタフェース的存在． データストアの実際の操作をカプセル化する．
リポジトリは，クライアントから切り離されているので容易に実装を変更できる． また最後のDBへのコミットはリポジトリが行うのではなく，クライアント側の責務である． リポジトリは変更の操作を行うだけで，トランザクション処理には関与しない．
14章
境界づけられたコンテキスト
複数のモデルを抱える巨大なプロジェクトがあった時，モデルごとにきちんと境界をしき外部のモデルに左右されない一貫性を保つ． このコンテキストごとに名前を設け，そのコンテキストと他のコンテキストの関係をコンテキストマップにまとめる．
腐敗防止層
二つのモデルが結合されて，モデルの一貫性が取れなくなった場合には腐敗防止層を設ける． この腐敗防止層は，二つのモデルの双方向の変換を行う．
15章
汎用サブドメイン
ドメインの中の優先度の低い処理群． OSSのライブラリなど実現に必要な手段のことだと思った．
ドメインビジョン声明文
コアドメインがやることを1ページのドキュメントとして記述する． このドメインビジョン声明文は開発が進むにつれて変化し，そのたびに改訂版を出す．
凝集されたメカニズム
ドメインに関係のない処理群． 汎用サブドメインとの違いはコードが無いので，いまいちわからなかった・・・
他にも色々ありましたが，また実践ドメイン駆動設計を読んでから読み直したいです
感想
長い．
それでも読んでて面白いと思う箇所が多く，実践を読んでまた理解を深めていけたらなと思いました． 精進します．
