Putting It All Together
- これまでの総集編
-
あくまで、本書提示のパターンは読者の考えの一助にすぎない。
読者の考えを置換するものではない- プロジェクトについては著者よりも読者のほうが詳しい
- 相談を持ちかけられることがあるが、5分程度の説明で特別なアドバイスを送れようはずもない
-
(設計に関する)決断は、二度と変更できないわけではない
-
例えばアーキテクチャレベルのリファクタリング
- Transaction Script -> Domain Modelとか
- 労力は計り知れないが不可能ではない
-
XPが嫌いでもこの3つはやれ
- CI
- TDD
- Refactoring
- 万能薬ではないが、あとで決断を変更しやすくなる
-
Starting with the Domain Layer
-
選択肢
- Transaction Script
- Table Module
- Domain Model
-
選び方
-
ドメインの複雑性により選ぶ
- どうやって定量化すんの(いやできない)
- 定性的にも測りがたい
- データソース層の実装の難しさ
-
-
Transaction Script
-
功
- 一番単純
- 手続型モデルにフィットする
- システムトランザクションをわかりやすくカプセル化する
- RDBの上(の層)に構築しやすい
-
罪
-
ビジネスロジックが複雑だと破綻する
- コード多重化
-
単純な買い物アプリケーション程度ならぴったり
- 値付けに特別なロジックがない
- 商品カタログある
- 買い物かごがある
- 以上
- それ以上複雑だと指数関数的にやばくなる
-
-
-
Domain Model
-
功
- オブジェクト指向大好きおじさんは常にこれを選ぶ
- 複雑なドメインロジックにはこれ一択
- 慣れればシンプルなロジックでこれを使うのも苦ではなくなる
-
罪
-
ドメインモデルの利用法の習得が難しい
- スキルを要する
-
RDBコネクション
-
オブジェクトDBを使う者も
-
でも大抵選択肢にはならない
- 主に非技術的な理由で
- 【補】枯れてないから、とか?
-
- オブジェクトモデルと関係モデルのミスマッチ
-
-
-
-
Table Module
- 前者2つの中間
- Transaction Scriptよりもドメインロジックをうまく取り扱える
- Domain Modelほど複雑なドメインロジックは扱えない
- が、RDBとよくフィットする
-
データソース層との兼ね合い
- 例: .NETプラットフォーム
-
データソース層としてRecord Setが適する
- ツールが充実している
- この場合Table Moduleが適する
-
ツール(ミドルウェアとか)との兼ね合い
- 理屈の上では、アーキテクチャありきでツールが選択されるべき
- 現実、そうではない
- ツールにアーキテクチャを合わせる
-
Table Module
-
.NETならこれが良い
- 親和性の高いRecord Setを取り回す仕組みが組み込まれているから
-
Down to the Data Source Layer
- ドメイン層の選択にもとづいて決める
Data Source for Transaction Script
-
Row Data Gateway
- 1レコード1オブジェクト
- オブジェクトはexplicitなインタフェースをもつ
- 【補】メソッドとかが生えているということでしょう
-
Table Data Gateway
- 1テーブル1オブジェクト
-
インタフェースはRow Data Gatewayに比べてimplicit
- レコード集合の構造に依存
-
【意訳】SQLをラップしただけな感じになる
- 原文: little more than a glorified map
-
プラットフォームとの兼ね合い
-
Record Setありきで動くようなツールがあるケース
- UIツール
- transactional disconnected record sets
- この場合Table Data Gateway
-
-
Transactional Scriptを選択した場合、ふつうO/Rマッピング不要
- 【補】Transactional Scriptを選択したからには、ドメインロジックが単純なはず
- ここにおいて、メモリ上のオブジェクトとRDB上のリレーションがきれいに対応する
- ミスマッチがないので、わざわざマッパを用意する必要がない
-
並列性の問題はまずない
- scriptがビジネストランザクションに対応づいているため
- スクリプト丸ごとシステムトランザクションで包める
-
例外: 読み出し、編集、永続化が別れているケース
- Optimistic Offline Lock使え
Data Source for Table Module
- Table Moduleを選定したということは、プラットフォームがRecord Setをサポートするツールを提供しているはず
-
Table Data Gateway使え
-
Record SetとTable Data Gatewayとは神の思し召しかというくらいマッチする
- 原文: made in heaven
-
-
Record Setが並列制御の仕組みを持っているとなおよい
-
Unit of Workを兼ねてくれる
- Maintains a list of objects affected by a business transation
and coordintates the writing out of changes
and the resolution of concurrency problems.
- Maintains a list of objects affected by a business transation
- 自前で並列制御しなくてすむので、髪の毛の減少を抑えられる
-
Data Source for Domain Model
- Domain ModelはDBとのコネクションが複雑になる
-
Domain Modelの複雑性による分岐
-
Active Record
-
ロジックが単純ならこれ
- DBと親しいのがたかだか数十クラス
-
DBアクセスを切り出すこともできる
- Table Data Gateway
- Row Data Gateway
- が、大して変わりはない
-
-
Data Mapper
- ロジックが複雑ならこれ
- Domain Modelを可能な限り他層から切り離す人
-
実装たいへん
- 作るな
- ツール使え
-
O/RをマップするならUnit of Workを強く推奨
- 並列制御のキモ
-
The Presentation Layer
- 下層の選択とは比較的独立している
-
クライアントどうする
- Webブラウザ
-
rich-client
-
Webブラウザよりも良いUI
- 【補】できることが多い、くらいの意味か
- クライアントアプリケーションのデプロイが必要
-
-
著者はWebブラウザ推し
- rich-clientはプログラミングの手間が大きい
- Webブラウザで実現できないならrich-client
- 以下、Webブラウザ前提
-
MVC使え
- Mの話は済んでいる(Domain Layer, Data Source Layer)
- CとVをどうするか
-
ツールとの兼ね合い
-
Visual Studio
- Page Controller/Template Viewが一番簡単
-
Java
-
フレームワーク使え
- 書籍執筆当時はStrutsが人気
- このフレームワークではFront Controller/Template View
-
-
-
自由なら?
-
サイトがドキュメント指向(静的・動的ページを出し分けるようなやつ)なら
-
Page Controller
- An object that handles a request for a specific page or action on a Web site.
- input controllerの一つ
- 【補】Laravelの「Controller」はこれ
- 【補】比較的シンプルなサイト、という意味か
-
-
ナビゲーションとUIが複雑
-
Front Controllerも使うことになる
- A controller that handles all requests for a Web site.
- input controllerの一つ
-
リクエストの処理を共通化する人
- セキュリティ
- i18n
- 特定のユーザの特別なビュー出す
- 【補】route middleware的な感じ
- 【補】Page Controllerが複雑になるので、共通処理を切り出したくなるということかな
-
-
-
ビューの選択
- 執筆当時、Template Viewが優勢
-
著者はTransform View推し
-
テスタビリティ高い
- 【補】関数的にXML等を加工していくからかな
-
-
ルック・フィールの異なる複数のビューが必要ならTwo Step View
- 【補】共通の論理ビューを出してから、2段目でルック・フィールを適用してレンダリング
-
下層との連絡
-
可能な限り同一プロセス内であることが望ましい
- はやい
- プロセス間通信やリモートプロシージャコールは遅い
-
やむを得ず行うなら、遅い通信の回数を少なくする工夫をする
-
ドメイン層にRemote Facadeを立てる
- 【補】coarse-grainedなインタフェースを提供するFacade
- Data Transfer Objectで、伝送するオブジェクトをまとめる
-
-
英語
-
pundit
- An expert in a particular subject or field who is frequently called upon to give their opinions to the public.
-
prod
- Stimulate or persuade (someone who is reluctant or slow) to do something. ‘they attempted to prod the central bank into cutting interest rates’ More example sentences
-
panacea
- A solution or remedy for all difficulties or diseases.
- 万能薬
-
fill the bill
- ぴったり要求にかなう
-
look down one’s nose
- 見下した態度を取る
-
zealot
- A person who is fanatical and uncompromising in pursuit of their religious, political, or other ideals.
-
fanatical
- Filled with excessive and single-minded zeal.
-
finesse
- [mass noun] Impressive delicacy and skill.
- [with object] Bring about or deal with (something) by using great delicacy and skill.
-
inexorably
- In a way that is impossible to stop or prevent.
-
focal
- Relating to the centre or most important part.