Java EE勉強会
MenuBar
編集
添付
凍結
新規
最終更新
一覧
単語検索
DDD
/
Layered Architecture
Menu
Top
JavaEE勉強会
参加するには
FAQ
MakingSenseofStreamProcessing
MicroservicesVsSOA
ModernJavaEEDesignPatterns
BSA
EIP
DSL
DDD
議事録
最新の20件
2023-11-24
MicroservicesVsSOA/The World of Service-Based Architectures
2020-11-14
DDD/Knowledge-Rich Design
MakingSenseofStreamProcessing/Example Implementing Twitter
2020-10-28
EIP/Aggregator
2019-12-18
EIP/Publish-Subscribe Channel
2018-06-10
FrontPage
2017-07-08
MakingSenseofStreamProcessing/Materialized Views Self-Updating Caches
MakingSenseofStreamProcessing/Summary Four Database-Related Ideas
MakingSenseofStreamProcessing/The Unbundled Database
MakingSenseofStreamProcessing/Conclusion
MakingSenseofStreamProcessing/Streaming All the Way to the User Interface
MakingSenseofStreamProcessing/4. Materialized Views
2017-06-11
MakingSenseofStreamProcessing/1. Replication
MakingSenseofStreamProcessing/Bringing the Unix Philosophy to the Twenty-First Century
MakingSenseofStreamProcessing/2. Secondary Indexes
MakingSenseofStreamProcessing/3. Caching
MakingSenseofStreamProcessing/How Databases Are Used
MakingSenseofStreamProcessing/Composability Requires a Uniform Interface
2017-03-25
MakingSenseofStreamProcessing/Unix Architecture versus Database Architecture
MakingSenseofStreamProcessing/Turning the Database Inside Out
階層化アーキテクチャ (P68-P75)
†
要約
†
LAYERED ARCHITECTURE
†
問題
短期間に容易な方法で実装するため、以下のことが発生している。
ビジネスオブジェクトに、UIコードやDBコード、その他のサポートコードが含まれている。
UIウィジェットやDBのスクリプトに、ビジネスロジックが含まれている。
ドメイン関連のコードが他のコードに拡散し、それを見て推論するのが難しい。
UIの変更がビジネスロジックの変更になることがある。
ビジネスルールの変更に、UIコードやDBコード、その他の要素の注意深い追跡が必要になる。
首尾一貫したモデル駆動オブジェクトの実装は非実用的になる
自動化テストがやりにくい
関連する技術やロジックでプログラムを単純にしておかないと、理解するのが不可能になる。
問題の解決方法についての説明
複雑なタスクのプログラム作成は関心事の分離を要求し、分離により異なる部分の設計に集中できる。
ソフトウェアシステムの分け方には色々あるが、経験と慣例に LAYERD ARCHITECTURES に収束している。
層の価値は、特定の局面を専門化することである。
概念的な4つの層
ユーザインタフェース(プレゼンテーション層)
情報の表示、ユーザのコマンドを解釈を行う。
アクターとしては、別システムということもある。
アプリケーション層
タスクの進行・調整や、下位層への作業の委譲を行う。
ビジネスルールや知識を含まない。
ドメイン層(モデル層)
ビジネスの概念や状態、ビジネスルールを表現する役割を担う。
インフラストラクチャ層
上位層を支える一般的な技術(メッセージ送信、永続化など)を提供する。
解決方法
複雑なプログラムは層を分離し、密接した層・下位層のみ依存し設計する。上位層とは疎結合になるようにする。
ドメインモデルに関連したコードに集中し、他の層から分離する。
ドメインオブジェクトはドメインを表現することに集中でき、モデルは本質的なビジネス知識を得て、豊かで明確になるように発展できる。
分離により各層が綺麗にデザインされ、各層の維持が楽なり、パフォーマンス改善や柔軟性アップする。
オンライン機能の層の分割
†
単純化したオンラインバンキング機能(資金移動)を題材に、階層化の例を提示。
層の関連
†
層は、上位層から下位層の要素を使用・操作する一方向な疎結合。
ただし、下位層から上位層へやりとりには、コールバックやOBSERVERSと言ったパターンが必要になる。
UIをアプリケーション層やドメイン層に繋ぐパターンとして、MODEL-VIEW-CONTROLLER(MVC)などがある。
インフラストラクチャ層は、ドメイン層の下にあり、ドメインの特定の知識ではなく、メッセージ送信インタフェースといったサービスを提供する。
SERVICES
は、アプリケーション層とドメイン層から要求される。
SERVICEのスコープの適切な選択、SERVICEのインタフェースの適切なカプセル化をすることで、疎結合にできる。
インフラストラクチャ層はSERVICEとして上位層から呼ばれるものばかりでない。
技術的なコンポーネントによっては、他層の基本機能をサポートしたり、他層間を関連付けるメカニズムを提供することもある。
そのような「アーキテクチャフレームワーク」は、他の部分の設計に大きな影響におよぼす。
アーキテクチャフレームワーク
†
優れたアーキテクチャフレームワークとは難解な技術的問題を解決しながらも、ドメインの開発者をモデルを表現する(という本来の責務に)専念させる。
しかし、余計な条件やヘビー級の実装によっては邪魔になる。
アーキテクチャフレームワークを適用する際は、ドメインモデルの実装を形成する事に集中する必要がある。
全てのフレームワークの特徴を使用するのではなく、最も役立つフレームワーク機能のみ適用する。
実装とフレームワークとの結合を減らし多くの柔軟性を許容する。
アーキテクチャフレームワークが正しく進化し続けるならば、アプリケーション開発者はビジネス問題のモデル化に集中でき、生産性・品質の改善へとつながる。
複雑なフレームワークはアプリケーション開発者を束縛することもあり、技術的な解決に対する強い興味には警戒しなければならない。
担当者のつぶやき
†
みんなの突っ込み
†
LAYERED ARCHITECTURE
p.70以降の2段落が最初の●(黒丸)2つに集約されているようですので、少し補わせてください。
"LAYERED ARCHITECTURE"が求められる原因は、"business object"にUIやDBアクセスロジックを書いてしまうことの弊害、つまり、「わかりにくい」「見た目のちょっとした変更がビジネスロジックに影響を与えてしまう」「ビジネスルールを変更するためにUIロジックを丁寧に追わなければならない」といった点に求められています。
解決策として、「関心事の分離(separation of concerns)」つまり、"LAYERED ARCHITECTURES"が提示されます。
そこでとりわけ強調されるのが、要約に書かれているように、「ドメインモデルに関連するコードはドメインレイヤに集約させること」であり、そうすることで「モデルは本質的なビジネスについての知識を十分にそして明確にとらえられるように成長することが可能となる」とあります。
Relating the Layers
最後の●の訳が【多層の基本機能=アーキテクチャフレームワーク】のようにも読めるので
インフラ層もSERVICEとして他から呼ばれるものばかりではないとした上で「技術的な構成要素によっては他レイヤの基本的な機能を直接サポートしたり、他レイヤ間を関連づけるメカニズムを提供することもある。このような、いわば『アーキテクチャフレームワークは』・・・」ということで次につながっています。
Architectual Frameworks
最初の●ですが、「優れたアーキテクチャフレームワークとは難解な技術的問題を解決しながらも、ドメインの開発者をモデルを表現する(という本来の責務に)専念させるものだ。しかし、なかなかうまくはいかないものだ」です。
蛇足ですが、最後の「よくできたフレームワークは往々にしてアプリケーション開発者を束縛するものだ」は、フレームワークを作るひとは皆さん抱えているジレンマなんだと思いました。 --
和智
?
2008-09-27 (土) 01:55:10
LAYERED ARCHITECTURE は省略し過ぎました。太字の部分中心に修正しました。
Relating the Layers および Architectual Frameworks についてもご指摘ありがとうございます。修正しました。 --
佐々木
?
2008-09-27 (土) 03:11:48
まとめ (
議事録
)
†
Menu
Top
JavaEE勉強会
参加するには
FAQ
MakingSenseofStreamProcessing
MicroservicesVsSOA
ModernJavaEEDesignPatterns
BSA
EIP
DSL
DDD
議事録
最新の20件
2023-11-24
MicroservicesVsSOA/The World of Service-Based Architectures
2020-11-14
DDD/Knowledge-Rich Design
MakingSenseofStreamProcessing/Example Implementing Twitter
2020-10-28
EIP/Aggregator
2019-12-18
EIP/Publish-Subscribe Channel
2018-06-10
FrontPage
2017-07-08
MakingSenseofStreamProcessing/Materialized Views Self-Updating Caches
MakingSenseofStreamProcessing/Summary Four Database-Related Ideas
MakingSenseofStreamProcessing/The Unbundled Database
MakingSenseofStreamProcessing/Conclusion
MakingSenseofStreamProcessing/Streaming All the Way to the User Interface
MakingSenseofStreamProcessing/4. Materialized Views
2017-06-11
MakingSenseofStreamProcessing/1. Replication
MakingSenseofStreamProcessing/Bringing the Unix Philosophy to the Twenty-First Century
MakingSenseofStreamProcessing/2. Secondary Indexes
MakingSenseofStreamProcessing/3. Caching
MakingSenseofStreamProcessing/How Databases Are Used
MakingSenseofStreamProcessing/Composability Requires a Uniform Interface
2017-03-25
MakingSenseofStreamProcessing/Unix Architecture versus Database Architecture
MakingSenseofStreamProcessing/Turning the Database Inside Out