POSA 本でアーキテクチャパターンを勉強しよう

• パターンとは何か？
• アーキテクチャパターン「混沌から構造へ」より「Layers（レイヤパターン）」
• アーキテクチャパターン「混沌から構造へ」より「Pipes and Filters」
• アーキテクチャパターン「混沌から構造へ」より「Blackboard」

混沌から構造へ - レイヤ（Layers）

アーキテクチャドキュメントを見ると、大抵システムの全体像は層ごとに分割されて記述されているものです。以下のような3層構造を見たことがある人は多いのではないでしょうか。レイヤパターンは、システムをいくつかの層に分割するパターンです。

よく見かけるレイヤ構造（by Kodougu）

レイヤパターンは前提として、「分割が必要な大規模なシステム」というものがあります。たとえば、PHP で一画面だけで作るような小規模なシステムにレイヤパターンを採用する必要はありません。

とはいえ、広く見るとたとえばメモリ管理などの低レベルな処理は、PHP という下位レイヤに任せているという見方もできなくはないので、大抵のシステムは巨大なレイヤ構造の中に存在しているという言い方はできます。

「設計」という視点に立てば、上位レベルのレイヤも下位レベルのレイヤも見ればきりがないので、レイヤを検討する際は「スコープを決める」ことが大切です。個別のシステムのアーキテクチャを検討する場合は、前述の PHP は技術選択の問題になるわけですから、アプリケーションの構造を検討する際にはスコープ外となるわけです。

課題

レイヤが必要とされるような状況はどのようなものでしょうか。一つは、前述の3層構造で言えば、プレゼンテーションレイヤとドメインレイヤのギャップが大きい場合が挙げられます。

たとえば、簡単なウェブアプリケーションの場合、データベースのテーブルと画面設計にあまりギャップが発生しません。Ruby on Rails でデータベースから画面を自動生成する機能（Scaffold）がありますが、このような画面を持つアプリの場合、レイヤ構造を検討する必要はないでしょう。

しかし、複数のテーブルからデータを持ってきて組み合わせて画面を作るような場合、ドメインレイヤのモデルをプレゼンテーションレイヤで使うモデルに変換する作業を行わなくてはならない場合があります。こうした責務をサービスレイヤに任せるという選択肢があるのですが、この場合、プレゼンテーションレイヤとドメインレイヤは直接的にやり取りしなくなり、サービスレイヤを介するようになります。

このような場合はレイヤを検討していると言えるでしょう。レイヤがどのような構造を持っているのかは後述しますが、水平方向にシステムを分割して、相互作用のルールを定めることになります。

今挙げた例の裏側には、「上位レベルの要件を実装するには、下位レベルの構造が違うもしくは粒度や抽象度が合わない」という問題が隠れています。

その他、レイヤを検討する場合、「異なるプラットフォームへの移植性」「下位レベルのレイヤの再利用性」「変更による影響範囲の局所化」「似たコンポーネントをあるレイヤに集めることによる理解容易性の確保」「パフォーマンス」などのフォースのバランスを取る必要があります。