前回のふりかえり 第7章の主旨 ファクトリ・リポジトリなどのパターンを実際のプロジェクトにどう適用するかの説明 第3部 より深い洞察へ向かうリファクタリング DDDがやりたいのは、ドメインについての深い理解をとらえたモデルを見つけること ↑のモデルが…

前回のふりかえり 第6章(リポジトリ)の主旨 DBなどに永続化されたオブジェクトを取り出してインスタンス化する(再構成する)クラス リポジトリが上記の責務を負うことで、永続化層への問い合わせ処理をカプセル化し、モデルに焦点を合わせられるようにする 第…

前回のふりかえり 第6章(ファクトリ)の主旨 ファクトリはオブジェクト生成を責務として担うもの オブジェクトや集約の複雑な生成作業をファクトリに任せることで、オブジェクト本来の責務に集中することができる。 第6章 リポジトリ(REPOSITORIES) DBなどに…

前回のふりかえり 第6章(集約)の主旨 ライフサイクルの長いオブジェクトの整合性を保つことが、ドメインオブジェクトを扱うことの課題になってくる。 そのような課題に立ち向かうために 集約・ファクトリ・リポジトリといった要素を使う。 集約は関連するオ…

前回のふりかえり 第5章の主旨 モデルを構成するものとして エンティティ・値オブジェクト・サービス の3つの要素がある。 オブジェクト間の関連・結合度を下げることで1つ1つの要素に集中することができ、ドメインを扱いやすくする。 モデルの本質的な(その…

前回のふりかえり 第4章の主旨 MDDを実現するには、モデル要素であるドメインオブジェクトを、他の機能から分離させる必要がある。 その手法として、レイヤードアーキテクチャを利用できる。 ドメイン層として凝集度を高め、他の層から独立させる。 第5章 ソ…

前回のふりかえり 第3章の主旨 モデル駆動設計では、分析と設計で同じモデルを使う 分析と設計で別のモデルを使用すると、それぞれの作業で得られた洞察を反映できなくなる モデルと設計(≒コード？)はお互いが対応してなければならず、一方と変更したら他方…