JavaEE、.NETの開発をするプログラマーが理解しておくべき設計のパターン

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

Java EEプログラマーとしてこの十年間に出版された本のベストを選べと言われたら、この本は間違いなく最有力候補になると思います。この本ではPOJOという考え方を広め、従来J2EEでベストプラクティスとされていたEJBやWebサービスを使った過剰な分散オブジェクト化を非難し、O/Rマッピングやドメインモデルなど本来のオブジェクト指向設計を活かす方法を紹介しています。エンタープライズ開発の世界でオブジェクト指向プログラミングの技法を復権させてくれた名著で（日本と欧米ではPOJOの意義に対して微妙な解釈の違いがあるような気がする - 達人プログラマーを目指して）、Hibernate、Spring Frameworkなどの現代的なフレームワークに与えた影響も計り知れないと思います。
従来から、エンタープライズアプリケーション開発というのはきれいな設計などは後回しで、とりあえず人海戦術で作ればよいという考え方があったかと思います。（プログラマの値崩れ - プログラマーの脳みそ）
これは、業界の悪しき慣習ということももちろんありますが、上の立場の人だけでなく、プログラマーの側でも

• エンタープライズ開発はたいした技術力を求められない。
• 毎回カスタムメイドであり技術でがんばっても付加価値が少なく徒労に終わる。
• 言語やツールの背後にある設計思想と比べて、業務システムの設計は美しくなく魅力を感じない。
• 技術力のあるプログラマーがかかわる仕事ではない。

と考えている人が多いのではないのでしょうか。言語やツールなどにこだわるプログラマーは多いのですが、システムの設計そのものに関心のあるプログラマーが少ないのは残念なことです。しかし、この本を読むと、そうした一般のどろくさいイメージとは逆に、本来エンタープライズ開発はオブジェクト指向などを活用した頭を使った設計技法の格好の対象とするべきということが理解できます。

• 業務システムは大量のデータを効率的に扱う必要がある
• 業務システムは大量のユーザーのリクエストを処理する必要がある
• 業務システムの要件はきわめて複雑で把握しにくい
• 業務システムの要件は変化する
• 業務システムのサポートする機能は大規模なことが多い
• 業務システムは長期にわたって利用される
• 業務システムは大量の別システムと統合する必要がある

したがって、本来は、よほど小規模な単純なシステムでもない限り、1機能1クラス（侵略的なフレームワーク - 達人プログラマーを目指して）や全部staticメソッド（業務システムでオブジェクト指向は必要か？ - 達人プログラマーを目指して）などというばかげた規約で作ってよいはずがないのです。1〜2年目の初心者プログラマーには難しい内容であると思いますが、上級プログラマー、アーキテクトと呼ばれる立場の人であれば、必読書だと思います。会社で時間を作って勉強会をするのもよいと思います。
日本語訳が出ていますが、周りの評判を聞いても読みづらいという感想を持たれる人が多いのは残念なことです。そうかといって原書はファウラー独特の砕けた表現がところどころにあり、英語力が高くないとこれまた理解が難しいです。とりあえず、パターンカタログは以下で読めます。
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?CatalogOfPofEAAInJapanese
ちなみに、タイトルから勘違いされやすいのですが、この本は一つの業務アプリケーションのアーキテクチャーに関するものでいわゆるエンタープライズアーキテクチャー（EA）とは扱っている内容が違います。