MENU

『ドメイン駆動設計』第8章 エヴァンス本 まとめ&感想

DDD

前回のふりかえり

  • 第7章の主旨
    • ファクトリ・リポジトリなどのパターンを実際のプロジェクトにどう適用するかの説明

第3部 より深い洞察へ向かうリファクタリング

  • DDDがやりたいのは、ドメインについての深い理解をとらえたモデルを見つけること
    • ↑のモデルがあれば、ドメインエキスパートの関心事をとらえて、実用的な設計を推進することができる
    • 第3部では、上記の目標を明確にしたうえで、目標を達成するためのプロセスを説明する

第8章 ブレイクスルー

ブレイクスルーとは

  • ブレイクスルーとは、リファクタリングを行う中で、モデルが実際に起きていることや、ユーザーが重視するものとより深いレベルで一致するようになる現象。
    • 深い(?)モデルは、小規模なリファクタリングが連続で行われることで、徐々に姿を現すことが出来る
    • コードとモデルを改良することにより開発者の視界は明確になっていき、洞察のブレイクスルーをもたらす可能性が生じていく。

→　ブレイクスルーはテクニカルではなく出来事

ブレイクスルーが起きるとどうなるか

  • モデルが持つ不適切な制約、誤った関係性が明らかになる
    • 今まで見落としていた関係を発見してモデルに反映できる
  • ドメインエキスパートがモデル図を完全に理解できるようになる
    • 彼らがモデル図を理解できないのであればドメインへの理解が不完全な可能性がある

※　ブレイクスルーはモデルを大きく変化させる。深いモデルへの移行は発想の転換であり、設計は大幅に変更されることになる(つまりやることがめちゃくちゃ増える)

ブレイクスルーを起こすには

  • ブレイクスルーが起こるのは、適度なリファクタリングが何度も行われた後。起こそうとして起こるものではない。
  • その舞台を整えるために...
    • 知識をかみ砕き、強固なユビキタス言語を育成するのに集中する
    • 重要なドメインの概念を探求して、それをモデルで明示する(9章参照)
    • 設計をよりしなやかになるように改良する(10章参照)
    • モデルを蒸留する(15章参照)

→　こうした予測可能な方策を推し進めることで、モデルや設計がより明確になる →　一度ブレイクスルーを起こすと、ユビキタス言語に基づくコミュニケーションが改善される。それによって新たなブレイクスルーを誘発することもできる

思ったこと・気になったこと

  • 8章まで来たが、やはり重要なのは「開発者とドメインエキスパートが同じ言葉で話すこと」「モデルを改良し続けること」なんだなあ
  • 次章移行への布石感が強い章だった

参考