第2部 モデル駆動設計の構成要素

• ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしている
• 本書は責務行動設計(responsibility-driven design)の原則に従う所が大きい
  • オブジェクト指向入門
  • 契約による設計
  • 実践UML
• 基本原則がモデル駆動設計をどのように支えているかを理解する必要がある
• ナビゲーションマップ
  • パターンと、パターンの相互の関係を示している
  • 図が強い、この時点じゃ何を言っているかがさっぱり
  • パターンランゲージを読むとなんとなく
  • 多分このあと何度もこの図に戻って来たりするのではないだろうか
  • これらの標準パターンを共有すれば、設計に秩序がもたらされ、チームメンバーが互いの仕事を理解しやすくなる。この標準パターンを使うことでユビキタス言語も成長する
• 手の込んだモデルは複雑さを断ち切ることができるが、ただし、それは基本に注意が払われたときだけ。その結果として得られる詳細な要素を、チームは自信を持って組み合わせることができる。

第4章 ドメインを隔離する

• モデル要素を見たときに１つの体系として理解できる必要がある。
  • 体系 、システム、全体を俯瞰できる、夜空
  • モデル要素とは、モデルの中の要素？それとも一個一個の構成要素のこと？
• より多くのオブジェクトが入り混じった中から、モデル要素を拾い上げるように矯正されるようなことはあってはならない。夜空に星座を見つけ出すようなことはしてはいけない。
  • 点と点、点と線
• ドメインオブジェクトはシステムの他の機能から切り離す必要がある

レイヤー化アーキテクチャー

• ユーザインターフェース

• アプリケーション

  • このレイヤは薄く保たれる

• ドメイン

  • この層がビジネスソフトウェアの核心である
  • 全ての振込には、それに対応する引き落としがある

• インフラストラクチャ

  ​

• レイヤ内のどの要素も同じレイヤの他の要素か、その**「下にある」**レイヤの要素にしか依存しない

• 設計における最も重要で凝集度の高い側面を隔離するレイヤを選び出す

  • 凝集度 : あるコードがどれだけそのクラスの責任分担に集中しているかを示す尺度である。from wiki
  • cf. coupling

• レイヤの価値は、それぞれがコンピュープログラムにおける特定の側面を専門的に扱うことにある。

　文献 : ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

レイヤを関係づける

• レイヤ同士は疎結合

• 設計の依存関係は1方向にだけ向けられる

  • サービスを提供する対象のドメインの特定の知識は持ってはならない
  • インターフェースとして提供される操作
  • サービス：このインターフェースはモデル内で独立していて、カプセル化された状態を持たない

• 下から上のレイヤをどうしても呼び出す時は オブサーバやコールバックを利用

• UIをアプリケーション層とドメイン層に結びつけるパターン

  • MVC
  • Model View 分離パターン
    • アプリケーションコーディネーター

• アプリケーション層をシンプルにして、本来の仕事だけに集中した状態を保つ

  • ex. メッセージをいつ送信するかは知っているが、どのように送信するかまでは背負い込まない

アーキテクチャーフレームワーク

• もっとも良く出来たアーキテクチャーフレームワークは、複雑な問題を解決する一方で、ドメイン開発者がモデルを表現することに集中できる

• しかし、フレームワークは、ドメインについての設計を制限する前提を多く持ちすぎたり、容易に開発の妨げになりうる。

  ​

• フレームワークを適用する場合、チームはその目標に集中しなければならない

• フレームワークの持つ欠点の多くを避けるためには、万能の解決策を探してはならない

• 難しい問題を解決するために、必要なものだけを選んで適用すればよい

  ​

• フレームワークの最も価値がある部分以外に対して、実装とフレームワークの結合度を下げる

• 表現力豊かな状態

• 技術的な解決策に熱中しないように注意する

  ​

ドメイン層はモデルが息づく場所

• ドメインの実装をプログラムの他の関心事から分離する　

利口なUIアンチパターン

• レイヤ化アーキテクチャのようなパターンが、ドメイン層を隔離するために必要になる理由と、それがどういう時なのかを明確にするために、ここでは利口なUIの話を敢えてします。
• 本書の文脈ではアンチパターン
• 利口なUIも他の文脈においては正答なパターンとなることもある
• 4GLって初めて聞きました

利口なUIを使うメリット

• 単純なアプリケーションの場合、生産性が高く、すぐに作れる。
• 誰でも開発できる。
• 単純なシステムの拡張ならば容易に対応できる。
• 関係データベースは上手く機能し、データレベルでの統合が実現される。
• 変更による影響が、それぞれ特定のユーザインターフェースに限定されるため、アプリケーションが引き継がれた場合、保守プログラマは自分が理解できない部分をすぐに作り変えられる。

利口なUIを使うデメリット

• アプリケーションの統合は困難で、データベースを経由させるしかない

• ふるまいが再利用されることも、ビジネスの問題が抽象化されることもない。

• ビジネスルールは、適用先の操作それぞれで複製されることになる。

• 迅速なプロトタイピングやイテレーションを行おうとしても、自然と限界に行き当たる。抽象度が欠けているため、リファクタリングの選択肢が制限されるから。

• 複雑さによってすぐに覆い尽くされてしまうので、成長しようとしても、単純なアプリケーションを追加することができない。より豊かな振る舞いが実現できるようになる、といった優雅な道は存在しない。

• モデル駆動設計に取り組むチームは、最初からそれにふさわしいやり方で設計する必要がある

• 最初の一歩を踏み出す先が、ドメインレイヤを隔離したモデル駆動

• アーキテクチャがドメインに関連するコードを隔離して、凝集度が高いドメインの設計が、システムの他の部分

• それをできるようにしているなら、そのアーキテクチャはおそらくドメイン駆動設計を支えられるだろう。

• モデル駆動設計に取り組むつもりなら、歯を食いしばり、必要な専門家を取り揃えた上で、利口なUIを避けるべきである。

  • アーキテクチャを妥協しない

• 表現力豊かな実装

個人的な学び

• ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしている
• レイヤー化アーキテクチャー とフレームワークは別物であり、時にはフレームワークの制約が理想的なモデルの表現を制限する
• 難しい問題を解決するために、必要なものだけを選んで適用すればよい
• 実装とフレームワークの結合度も下げたい
• 表現力豊かな状態というものを理解したい
• 技術的な解決策に熱中しないように注意する
• 利口なUIが絶対悪ではない、なぜレイヤー化アーキテクチャーを選ぶのかを良く理解する