PofEAA でファウラーが対象とする Enterprise Application

ちょっとしつこいかなと思いつつ．．．
PofEAA は DB にアクセスするだけの単純なアプリケーションを対象としていないのか？
そうではないと思います．
例えば 5 ページからの「Kinds of Enterprise Application」では，Enterprise Application の例として次の 3 つが紹介されています．

ショッピングサイト

膨大なユーザ数をサポートしなければならないが，ドメインロジックは単純．

プロセスオートメーション

ユーザ数が少ないのでショッピングサイトよりもシンプルなシステム (アプリケーションのことではなく，ハードウェアを含めた話だと思われ) になりやすい．
ビジネスロジックは複雑．

小さな企業の経費管理システム (？ expense-tracking system)

少数のユーザから利用され，単純なロジック，HTML によるプレゼンテーションを持つ．

Enterprise Application の例として出されている 3 つの例のうち 2 つが単純なロジックしか持っていないということに注目すべきでしょう．特に最後の例は，まさに「DB にアクセスするだけ」の例のように見えます．
そして．．．

A third example point is a simple expense-tracking system for a small company. Such a system has few users and simple logic and can easily be made accessible across the company with an HTML presentation. The only data source is a few tables in a database. As simple as it is, a system like this is not devoid of a challenge. You have to build it very quickly and you have to bear in mind that it may grow as people want to calculate reimbursement checks, feed them into the payroll system, understand tax implications, provide reports for the CFO, tie into airline reservation Web services, and so on.

単純なものでもより素早く作らなくてはならないということ，将来にわたって単純であり続けるとは限らないということから挑戦のしがいはあるということです．そこにパターンを適用する価値はあるということではないでしょうか？
さらに．．．

Each of these three enterprise application examples has difficulties, and these are different difficulties.

単純そうなものにも複雑なものとは異なった難しさがあるということです．

そして PofEAA のパターンカタログを見ていくと，単純なロジックしか持たないようなアプリケーションにも使えそうなものがそこら中に転がっているように思えます．

Chapter 9 Domain Logic Patternss

発端となった Transaction Script とか．これはむしろ複雑なロジックを持つアプリでは使えないパターン．「DB にアクセスするだけ」御用達では？

Chapter 10 Data Source architectural Patterns

Table Data Gateway がいわゆる DAO (MS っぽいから DAO って用語はイヤなんだって) なパターンで普通に使えるはず．
Row Data Gateway は以下みたいなの．今となってはベストプラクティスという気はしませんが，単純なロジックしか持たないアプリでも有効だったはず．

order = orderFinder.find(key);
order.setXxx();
order.update();

Chapter 11 Orject-Relational Behavioral Patterns および Chapter 12 Object-Relationa Structural Patterns

ロジックの複雑さには関係なく，今更自前で作ることはなさそうなパターン．
Hibernate などで使われているものが多いので，単純なアプリでも Hibernate を使う価値があるなら有用といえるのではないかと．

Chapter 13 Object-Relational Metadata Mapping Patterns

DB にアクセスするだけの単純なアプリケーションを大量に作成しなければならない場合に役立つパターン．
そんな場合はやっぱりメタでしょ．

Chapter 14 Web Presentation Patterns

今となっては自前で考えるものではないけど，ロジックの複雑さとは関係なく有効．
Struts などを使えばこのパターンの多くを使うことになると思ふ．

Chapter 15 Distribution Pattern

これはさすがに単純なロジックでは使わない．っていうか複雑でも使わないと思うけど．

Chapter 16 Offline Concurrency Patterns

複数のユーザから同時に利用されるシステムならロジックの複雑さに関係なく使えるというか普通使ってるでしょ．

Chapter 17 Session State Patterns

意識してなくても Server Session State を使ってる．デフォ．
WAS3.0 では Database Session State が使えたというかデフォでそうなったような気のせいが．

Chapter 18 Base Patterns

ユーティリティ的なパターンが多い．
インタフェースと実装クラスを別パッケージにしろ (Separated Interface) とかそんなのまで．
ロジックが単純でも使えるもの多そう．

むしろ，複雑なロジックを持ったドメインモデルにこそ効果的といえるようなパターンの方が見あたらないと思います．Domain Model で解決できるとは思えないし．

これらのことから，ファウラーたんがいうところの Enterprise Application は，「その辺に転がってるちっちゃい業務システム」や「ユーザとDBの間つないでるだけのようなシステム」も含まれていると私は思います．
ま，こんな解釈は人それぞれで全然構わないんですけどね．ただ，「意味を取り違えてる」ってのが気になったのです．
でも，こうやって確認して，少なくとも自分にとっての位置づけは変わらなかったし取り違えてなかったということで終了．