PoEAA Part 1 Chapter 2 Organizing Domain Logic
前章の話
- アプリケーションを層分けしろ
- プレゼンテーション層
- ドメイン層
- データソース層
Organizing Domain Logic
- ドメインロジックを構成する設計は主に3種類
- Transaction Script
- Domain Logic
- Table Module
Transaction Script
- 一番シンプル
- ユーザの望む1アクションにつき1手続き
- 例えば、買い物システムなら
- メリット
- デメリット...ドメインロジックが複雑になるにつれ顕在化
Domain Model
- 複雑性に対処ときたらオブジェクト指向
- (少なくとも最初は)主にビジネスドメインで現れる名詞をオブジェクト化する
- 賃貸システムの例
- 賃貸
- 資産
- 契約
- 会計システムの例
- 契約
- 製品
- 収益認識ストラテジ
- Strategy Pattern
- 収益認識
- 賃貸システムの例
- Transaction Scriptとの違いは、シーケンス図を見れば一目瞭然
- Transaction Script: 中央集権型
- Domain Model: 各オブジェクトに処理を委譲
- 拡張が楽
- Transaction Script: 条件文の追加
- 影響大。すべてがブチ壊れる可能性がある
- Domain Model: Strategy Patternにしたがい、Strategyオブジェクトを追加する
- Strategyインタフェースに依存するので影響最小限
- Transaction Script: 条件文の追加
- 著者(Martin Fowler)くらいオブジェクト指向狂いになると、単純なケースでもDomain Modelを好むようになる
- こわくないよ みんなやってるよ
- オブジェクトとDBのマッピング
Table Module
- Transaction ScriptとDomain Modelの中くらい
- Domain Modelとの違いは、単一オブジェクトであること
- Domain Model: 1レコードにつき1オブジェクト
- Table Module: シングルトン
- レコードの集合(Record Set)について仕事する
- 個々のレコードについて仕事したいときはIDを渡す
- Transaction Scriptよりはコード多重化を排除しやすい
- Domain ModelよりはOOのテクニックを適用しづらい
- 継承
- ストラテジ
- etc.
- メリット ... ドメイン層以外とフィットする
Making a Choice
- 結局どれ使えばいいの
- 簡単な選択ではない
- 定性的には
- ドメインロジックの複雑性を定量的に図ることができないのであまり意味がない
- 実際的には、要件の初期分析を経験豊富な人にしてもらい、決めてもらうことになる
- Domain Model導入の初期コスト
- データソース層を成功に作りこむ必要があるため、Transaction Script, Table Moduleよりは高くなる
- チームの面子がOOに慣れていればある程度下げられる
- Table Moduleの強みは、環境がRecord Setを支援してくれるかによる
- .NETとかCOMとか
- ツールの支援等を受けられないとつらい
- 一度決めたら絶対変えられない、というものではない
- が、変えるのは注意とスキルを要する
- Transaction Scriptで始めて、「しくじった」と思ったら、ためらわずDomain Modelに向けてリファクタしろ
- Domain Modelで始めてTransaction Scriptに方向転換するのは、精巧に作りこんだデータソース層を単純化できない限り割に合わない
- そもそも3つの設計は排他的ではない
- いくつかのドメインロジックにだけTransaction Scriptを適用する
Service Layer
- ドメイン層をさらに2分割することは一般的
- 上: Service Layer
- 下: Domain Model, Table Module
- ※ Transaction Scriptを適用すべき単純なケースでは、わざわざ分割する必要はない
- Service LayerはAPIのようにふるまう
- Service Layerを通してドメインロジックにアクセスする
- Service Layerはトランザクション制御やセキュリティチェックを実装する場所としても有用
- Service Layerにどこまで仕事させる?
- 仕事しない側: Facade
- 振る舞いをもたず、低レベルなオブジェクトに委譲するだけ
- トランザクション、セキュリティチェックでラップする等
- 仕事する側: Transaction Script
- 中くらい: controller-entityスタイル
- 仕事しない側: Facade
- controller-entityスタイルはよく使われるが、著者は好まない
- ドメイン層の二分割の分け方は固定的なものではない
- 著者見解: Service Layerは、設けるにしても、薄く保つべき
- 基本的に不要
- アプリケーションが必要としたら追加する
- Service Layerにかなりのロジックを置く良い設計者もいる
- Randy Staffordとか
- 著者見解: Service Layerは、設けるにしても、薄く保つべき
英語
- behind the scenes
- Out of sight of the public at a theatre or organization.
- revenue
- Income, especially when of an organization and of a substantial nature.
- revenue recognition
- 収益認識
- warped
- Abnormal or strange; distorted.
- cast in stone
- Permanently fixed or firmly established; not subject to any amendment or alteration. Often used in the negative.
- tricky
- requiring care and skill because difficult or awkward.
- warrant
- Justify or necessitate (a course of action)
- go whole hog
- Do something completely or thoroughly.