7章の4ページ目で、ようやく DDD ( ドメイン駆動設計 ) パターンの登場。
Layered Architecture パターンを使って、ドメインモデルと他の要素を分離する。
プレゼンテーションやデータアクセスとの分離は当たり前。ここで出てくるのは、アプリケーション層とドメイン層の分離の具体例。
Eric Evans は、次の三つを「アプリケーション層」のクラスとして説明している。
Tracking Query (配送状況の問合せ)
Booking Application (貨物の登録)
Incident Logging Application (運送イベントの記録)
利用者が使う機能単位のクラスですね。アプリケーション層は、こういう視点と粒度のクラスを集める場所。
アプリケーション層のクラスのあるべき姿として2点を強調する。
・役割は「調整役」である。
・難しいことは自分では、一切やらない。ドメイン層に依頼して簡単に済ませる。
クラスの役割は「調整役」である、という記述は、レベッカ・ワーフスブラックの オブジェクト・デザイン の6つの役割(ロール)分類の「調整役」を指しているんでしょうね。
「調整役」とあっさり書いているが、説明不足ではなかろうか?それとも「オブジェクト・デザイン」くらい読んでいるのが常識なの?
とりあえず、私の今の理解を書いておきます。
「調整役」をアプリケーション層に分離する意図は、ドメイン層のモデルに「検索」や「登録」などの個別のアプリケーション要求が混ざり込み、モデルが複雑化することを防ぐことでしょう。
ドメイン層は、問題領域の知識の置き場所。
アプリケーション層は、利用者がやりたいことを定義(抽象化)したクラスの置き場所。
プレゼンテーション層は利用者に使いやすい画面を提供する。
アプリケーション層は、プレゼンテーション層に便利なメソッドを提供する。
ドメイン層は、アプリケーション層に便利なメソッドを提供する。
こうやって、いろいろな関心事を、それぞれの層に分離したほうが、ソフトウェアが理解しやすく、変更が容易になる(はず)。
Layered Architecture パターンを使って、ドメインモデルと他の要素を分離する。
プレゼンテーションやデータアクセスとの分離は当たり前。ここで出てくるのは、アプリケーション層とドメイン層の分離の具体例。
Eric Evans は、次の三つを「アプリケーション層」のクラスとして説明している。
Tracking Query (配送状況の問合せ)
Booking Application (貨物の登録)
Incident Logging Application (運送イベントの記録)
利用者が使う機能単位のクラスですね。アプリケーション層は、こういう視点と粒度のクラスを集める場所。
アプリケーション層のクラスのあるべき姿として2点を強調する。
・役割は「調整役」である。
・難しいことは自分では、一切やらない。ドメイン層に依頼して簡単に済ませる。
クラスの役割は「調整役」である、という記述は、レベッカ・ワーフスブラックの オブジェクト・デザイン の6つの役割(ロール)分類の「調整役」を指しているんでしょうね。
「調整役」とあっさり書いているが、説明不足ではなかろうか?それとも「オブジェクト・デザイン」くらい読んでいるのが常識なの?
とりあえず、私の今の理解を書いておきます。
「調整役」をアプリケーション層に分離する意図は、ドメイン層のモデルに「検索」や「登録」などの個別のアプリケーション要求が混ざり込み、モデルが複雑化することを防ぐことでしょう。
ドメイン層は、問題領域の知識の置き場所。
アプリケーション層は、利用者がやりたいことを定義(抽象化)したクラスの置き場所。
プレゼンテーション層は利用者に使いやすい画面を提供する。
アプリケーション層は、プレゼンテーション層に便利なメソッドを提供する。
ドメイン層は、アプリケーション層に便利なメソッドを提供する。
こうやって、いろいろな関心事を、それぞれの層に分離したほうが、ソフトウェアが理解しやすく、変更が容易になる(はず)。