アーキテクト向けのパターン本

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

Pattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Pattern-Oriented Software Architecture, Patterns for Resource Management (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture, Patterns for Resource Management (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture, A Pattern Language for Distributed Computing (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture, A Pattern Language for Distributed Computing (Wiley Software Patterns Series)

Pattern-Oriented Software Architecture: On Patterns and Pattern Languages (Pattern-Oriented Software Architecture)

Pattern-Oriented Software Architecture: On Patterns and Pattern Languages (Pattern-Oriented Software Architecture)

ここのところアーキテクチャーの話がいろいろ出たので、この機会に紹介させていただきます。このシリーズはPOSAシリーズとして、デザインパターン(GoF)と並んで、パターン本としてはかなり有名な本だと思います。ただし、正直なところ、かなりとっつきにくいというか、一度読んですぐに理解できるというタイプの本ではないですね。日本語訳は第一巻のみ出てますが、翻訳も部分的におかしいのではという箇所があり、パターンの記述テンプレートも冗長なため、頭から読むと退屈で読みづらいです。
このPOSAシリーズの中でも、私としては比較的最近に出版された第4巻が一押しですね。いわばパターンの総集編という感じで、このシリーズだけでなくGoFやPofEAAなど多くの本のパターンも集約し、100個以上のパターンがカテゴリーごとに、パターンシーケンスやパターン言語として体系的にまとめられています。パターンを単独で使うのではなくて関連するパターンを複数組み合わせて適用するという考え方を学ぶことができます。タイトルは「分散コンピューティング」専門の本のようですが、Layer、MVC、Command、Strategyなどおなじみのパターンが含まれており、Java EEなどの一般的な開発のアーキテクチャー設計やプログラム設計のヒントとして役に立つはずです。
こういう本を読むと、よく多くの人に勘違いされているように「設計=設計書」「設計する=設計書を書く」ということではなく、本来設計とは頭を使っていろいろな制約の中で最良の方式を考えるという知的な行為を指しているのだということに気づかされます。エンジニアリングとしては本来当たり前のことだと思いますが。
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してに書いたことも、結局のところ「設計=設計書」、あるいは、「設計=UML図」という固定観念を捨てて、本来設計(design)とはどういう行為なのかということを考えていただければ、より多くの方に納得していただけるのではないかと思います。プログラミングと設計が切り離せないというのは、設計が正しいか間違っているかのフィードバックを得る最適な手段が、たまたまプログラミングによって実際に試してみることなのだという考えによるものです。プログラマーとしてある程度経験を積んでいくとそういう考えが自然と身についてくるのですよ。

前の会社の同期が「設計は出来るけど、プログラミングは出来ない」と宣言してて唖然としたのを思い出した。

などというコメントは、まさに設計を作図行為と勘違いしていることよるものではないでしょうか?たいていそういう人の作った設計図は形式の上では設計書なのですが、パターン本にヒントがあるような設計の本質が書かれていることはほとんどなく、また、仮に設計らしい記述が書かれていてもそれが正しいかどうか何の保障もないのです。
第4巻を読んだのはPofEAAやwithout EJBを読んだ後だったので、「分散コンピューティング」と聞いて、最初は過剰な設計をもたらすちょっと時代遅れなアーキテクチャーの本と思って読んだのですが、意外にも実用的で私としてはお気に入りの本の一つになりました。(この本の前書きを最近はアジャイルなイメージのあるファウラーが書いているのもちょっと興味深いところです。)