ソフトウェアアーキテクチャの基礎 第2版 ―エンジニアリングに基づく体系的アプローチ

20章アーキテクチャパターン

9章で、アーキテクチャスタイルとアーキテクチャパターンの区別について説明した。おさらいすると、アーキテクチャスタイルは、物理アーキテクチャ・デプロイメント・通信スタイル・データトポロジーの違いによって区別されるトポロジーに名前が付けられたものだ。一方、アーキテクチャパターンとは、よく知られている書籍『Design Patterns: Elements of Reusable Object-Oriented Software』（邦訳『オブジェクト指向における再利用のためのデザインパターン』）[19]に触発されたもので、文脈に応じた問題への解決策を指す。

アーキテクチャパターンと「ベストプラクティス」（10章で詳しく説明）を区別することは重要だ。何かを「ベストプラクティス」と呼ぶことは、特定の状況が発生した際には必ずそのプラクティスを利用すべきという義務感を、アーキテクトに課せてしまっていることを暗に示している。「ベター（より良い）」プラクティスと呼べば議論の余地はできるかもしれないが、我々はそれを「ベスト」プラクティスと呼んでしまう。そのせいで、大勢のアーキテクトが思考を止め、常に同じ解決策に従うことになってしまう。

アーキテクチャパターンとソリューションを区別することも重要である。ツール・フレームワーク・ライブラリといった、ソフトウェア開発における多くのソリューションは、1つ以上のパターンをカプセル化している（実装方法によってパターンへの忠実度や他のパターンとの混在度合いは異なる）。まずは最も適切なパターンを特定する。そして、その後に最も適切な実装を選択することが重要だ。

この章では、代表的なアーキテクチャパターンをいくつか紹介し、本書の第II部