Transaction Script と Domain Model

そこかしこで話題になっているので，二年近くも積みっぱなしになっている PofEAA を引っ張り出してきました．読んでないけどファウラーたんのサイン付き♪
話題の二つのパターンは，パターンカタログの最初，「 Chapter 9: Domain Logic Patterns」で紹介されていました．この章では次の 4 つのパターンが出てきます．

Transaction Script
Domain Model
Table Module
Service Layer

このうち Service Layer は，UI などから Domain Logic にアクセスするための境界を提供するものらしいので，ちょっと毛色が違うみたい．
そして残りの 3 つが Domain Logic を設計・実装する際の選択肢ということになるようです．
ともあれ (JW)，ここでは Transaction Script と Domain Model について見ていきましょう．
．．．
と思ったのですが，面倒なので大雑把にまとめてしまうと．．．

Transaction Script: Domain Logic を「手続き」に配置する．
Domain Model: Domain Logic を「データ」と一緒に配置する．

ちなみに SQL の複雑さとかは関係ないみたい．何も書いてない気がします．

興味深いものとして，PofEAA の「Chapter 2: Organizing Domain Logic」には，Domain Logic の複雑さを横軸に，拡張の大変さ (Effort to Enhance) を縦軸にした (非科学的な) グラフが掲載されています (P29 の Figure 2.4)．
これによると，Transaction Script は Domain Logic が単純ならラクチンだけど，Domain Logic の複雑さに応じて指数関数的に大変さが増していくことになっています．
一方で Domain Model は，Domain Logic の複雑さに比例して大変さが増すことになっていますが，ある程度単純な Domain Logic では Transaction Script よりも大変らしいです．
ちなみに Table Module も Domain Logic の複雑さに対して指数関数的に大変さが増すことになっていますが，その程度は Transaction Script よりも穏やかで，常に Transaction Script よりもラクチンらしいです．ちょっと注目？

さてさて，ここからが本題．
Domain Logic の複雑さってなによ？
複雑な Domain Logic ってどんなもの？それだと本当に Domain Model が有利なの？

一言で複雑な Domain Logic といっても，いろいろな種類があると思うのですよね．
例えば私の経験だと，証券会社でのデリバティブ商品を評価するシステムなんかはかなり複雑といえば複雑でした．
デリバティブ商品というのは，複数の金融商品を組み合わせたり，時期の異なる取引を組み合わせたりして取引される商品で，先物やオプション，スワップ，さらにそれらを組み合わせたりしたものなどなどがあります．
ディーラーと呼ばれる人達はそれらの売買を繰り返すことで膨大な利益を生み出すのですが，野放図に取引させていると膨大な損失を出す場合もあるわけで，それを評価・管理するシステムがもてはやされた時代があったのです．最近は知らないけど．
そんなわけで (どんなわけで？)，この手のシステムって金融工学の専門家が考案した複雑な数学モデルが仕様書を埋め尽くしていたりします．
こういう世界では Domain Model はピッタリでしょう．なぜなら，そこにあるのは静的で受け身なもの，はぶさんいうところの「(パッシブな) 資源」がほとんどだからです．デリバティブ商品を売った・買ったとか，時価が変わったとかいうイベントに反応はするものの，発注などの「活動」は別のシステムによって行われたりしていました．そのせいか，こういう世界では「業務」って言葉は使ってなかったような記憶が (上で Domain Logic を業務ロジックと書かなかったのはそのためなのだ)．
なので，確かに難解な世界ではあるものの，結局は「資源」のポートフォリオを求めるくらいしかない世界という感じもするわけで，ポートフォリオってのは所詮 Composite Pattern なので，まさに OO なモデル図が大活躍する，見方によっては単純ともいえる世界なのです．
ちなみに「アナリシスパターン」でも例として出てくることから，ファウラーたんもこっち方面の経験がおありの様子．っていうか，PofEAA の Domain Logic に出てくる例もこの世界のものっぽい．「Product」って，製造業的な世界での商品 (製品) ではなくて，金融商品みたいなものではないのかな？まぁ，取引 (契約) が成立する時点とお金 (や商品) が受け渡しされる時点が異なるケース一般を意図しているとは思いますが．

でもでも，パッシブな資源がほとんどという Domain は決して多くはないはず．
たいていの場合，複雑になっていくのは「活動」の方じゃないでしょうか？様々な「資源」にまたがる複雑な「活動」．特定の「資源」の責務だと決めることが困難な「活動」．
そういう場合でも Domain Model なアプローチが有利になるのかはかなーり疑問です．っていうか，無理があると思う．
そんな場合は，複雑さと大変さのグラフも全然違ったものになるんじゃないかな？ Domain Model で対応できる複雑さはきわめて限定的なものじゃないかと書いてみるテスト．

そんなわけで (どんなわけで？)，個人的には Domain Model なアプローチは適用範囲が狭いと考えています．運がよければそんな開発に恵まれるかもしれませんが，滅多にないのではないかと．私的には 20 年で 1 件のみ．(;_;) ちなみにその 1 件は唯一の ODBMS (ObjectStore) を使ったシステムでもあります．いい経験だったかも〜．
んで，注目しているのは「UML によるビジネスモデリング (isbn:479731382x)」．っていうことを以前も書いてるわけですが，それからも積みっぱなし．．．心より恥じる．
つまりですね，先に書いたファウラーたんの図で，Domain Logic が複雑化したときに Transaction Script では変更が大変になっていくのはなぜかというと，Transaction Script は monolithic と見なされているからだと思うのですよ．PofEAA でも，Command Pattern なクラス一つで済ませちゃってるような感じ．それじゃあ複雑で大規模なものは作れないのは当然．でもそれは「手続き」の側にロジックを置くためではなくて，単に Separation of Concerns してないからというだけではないでしょうか？
その点，「資源」の方は「その辺に転がっていて拾い上げられるのを待っている」みたいにいわれるくらい，自然に細分化できてしまうのが有利なのかなぁ．
でもでも，「手続き」の方も OO なモデリングは可能で，それによって複雑さにも変化にも対応できる可能性はあるんじゃないかと期待してます♪

ともあれ (JW)，いつまでも積んでないでちゃんと読んでおけってことっすね．．．
心より恥じる．