<< 東京国立博物館 六波羅蜜寺の仏像 | main | 実践 ICONIXプロセス : 要件定義から実装まで >>

実践 Domain-Driven Design : アプリケーション層のクラス

7章の4ページ目で、ようやく DDD ( ドメイン駆動設計 ) パターンの登場。
Layered Architecture パターンを使って、ドメインモデルと他の要素を分離する。

プレゼンテーションやデータアクセスとの分離は当たり前。ここで出てくるのは、アプリケーション層とドメイン層の分離の具体例。

Eric Evans は、次の三つを「アプリケーション層」のクラスとして説明している。

Tracking Query (配送状況の問合せ)
Booking Application (貨物の登録)
Incident Logging Application (運送イベントの記録)

利用者が使う機能単位のクラスですね。アプリケーション層は、こういう視点と粒度のクラスを集める場所。

アプリケーション層のクラスのあるべき姿として2点を強調する。

・役割は「調整役」である。
・難しいことは自分では、一切やらない。ドメイン層に依頼して簡単に済ませる。

クラスの役割は「調整役」である、という記述は、レベッカ・ワーフスブラックの オブジェクト・デザイン の6つの役割(ロール)分類の「調整役」を指しているんでしょうね。

「調整役」とあっさり書いているが、説明不足ではなかろうか?それとも「オブジェクト・デザイン」くらい読んでいるのが常識なの?

とりあえず、私の今の理解を書いておきます。

「調整役」をアプリケーション層に分離する意図は、ドメイン層のモデルに「検索」や「登録」などの個別のアプリケーション要求が混ざり込み、モデルが複雑化することを防ぐことでしょう。

ドメイン層は、問題領域の知識の置き場所。
アプリケーション層は、利用者がやりたいことを定義(抽象化)したクラスの置き場所。

プレゼンテーション層は利用者に使いやすい画面を提供する。
アプリケーション層は、プレゼンテーション層に便利なメソッドを提供する。
ドメイン層は、アプリケーション層に便利なメソッドを提供する。

こうやって、いろいろな関心事を、それぞれの層に分離したほうが、ソフトウェアが理解しやすく、変更が容易になる(はず)。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM