キーコンセプト
図1-2で、アーキテクチャ内の各層が閉じているとマークされていることに注目してください。 これは、層状アーキテクチャ・パターンにおいて非常に重要な概念である。 閉じた層とは、要求が層から層へ移動するとき、その下の次の層に到達するために、そのすぐ下の層を経由しなければならないことを意味する。 例えば、プレゼンテーション層から始まったリクエストは、まずビジネス層を通過し、次に永続化層を経て、最終的にデータベース層に到達しなければなりません。
図1-2. 閉じた層とリクエスト アクセス
では、なぜプレゼンテーション層が永続化層またはデータベース層のいずれかに直接アクセスできるようにしないのでしょうか。 結局のところ、プレゼンテーション層からの直接のデータベース アクセスは、データベース情報を取得または保存するためだけに不必要な層の束を通過するよりもはるかに高速です。 この質問に対する答えは、分離の層として知られる重要な概念にあります。
Layers of isolation の概念は、アーキテクチャのある層で行われた変更が他の層のコンポーネントに影響を与えない、または影響を及ぼすことが一般的であることを意味します。 もし、プレゼンテーション層が永続化層に直接アクセスできるようにすると、永続化層内のSQLに加えられた変更は、ビジネス層とプレゼンテーション層の両方に影響を与え、コンポーネント間の相互依存性が高い、非常に密結合のアプリケーションを生み出すことになります。 このようなアーキテクチャは、変更するのが非常に困難でコストがかかります。
Layers of isolation のコンセプトは、各層が他の層から独立しており、アーキテクチャ内の他の層の内部動作についてほとんど、あるいはまったく知識がないことも意味します。 この概念の威力と重要性を理解するために、プレゼンテーション フレームワークを JSP (Java Server Pages) から JSF (Java Server Faces) に変換する大規模なリファクタリング作業を考えてみてください。 プレゼンテーション層とビジネス層の間で使われるコントラクト（例えばモデル）が同じままだと仮定すると、ビジネス層はリファクタリングの影響を受けず、プレゼンテーション層が使うユーザーインターフェースフレームワークの種類に完全に依存しないままです。
閉じたレイヤーは分離のレイヤーを促進し、したがって、アーキテクチャ内の変更を分離するのに役立ちますが、特定のレイヤーが開いていることが理にかなっている場合もあります。 たとえば、ビジネス層内のコンポーネントによってアクセスされる共通のサービス コンポーネント (たとえば、データおよび文字列ユーティリティ クラスまたは監査およびロギング クラス) を含むアーキテクチャに、共有サービス層を追加したいと仮定します。 サービスレイヤーを作成することは、アーキテクチャ上、共有サービスへのアクセスを（プレゼンテーション層ではなく）ビジネス層に制限することになるので、この場合、通常は良いアイデアです。 独立したレイヤーがなければ、アーキテクチャ上、プレゼンテーション層がこれらの共通サービスにアクセスすることを制限するものは何もなく、このアクセス制限を管理することが難しくなります。
この例では、新しいサービス層はおそらくビジネス層の下に存在し、このサービス層内のコンポーネントはプレゼンテーション層からアクセスできないことを示すでしょう。 しかし、これは、ビジネス層が永続性層に到達するためにサービス層を通過する必要があるという問題を提示し、まったく意味をなしません。 これはレイヤードアーキテクチャの古くからの問題で、アーキテクチャの中にオープンレイヤーを作ることで解決されます。
図 1-3 に示すように、この場合のサービス層はオープンとしてマークされており、リクエストはこのオープン層をバイパスして、その下の層に直接行くことが許可されていることを意味します。 次の例では、サービス層が開いているので、ビジネス層はそれを迂回して直接永続化層に行くことが許可されており、これは完全に理にかなっています。
図1-3. オープン レイヤーとリクエスト フロー
オープン レイヤーとクローズ レイヤーという概念を活用することは、アーキテクチャ レイヤーとリクエスト フロー間の関係を定義するのに役立ち、また、設計者や開発者がアーキテクチャ内のさまざまなレイヤー アクセス制限を理解するのに必要な情報を提供します。 アーキテクチャ内のどの層がオープンでありクローズであるか（そしてその理由）を文書化したり適切に伝達しなかったりすると、通常、テスト、保守、および配備が非常に難しい、緊密に結合した脆いアーキテクチャが出来上がります。