階層化アーキテクチャの顕著な特徴は、成分（関心事の分離）との間の関心事の分離です。本層の一層のみ組立処理ロジック。例えば、プレゼンテーション層のコンポーネントのみが唯一のビジネスロジックに対処するために、プレゼンテーションロジック、ビジネス層成分を処理します。個別のコンポーネントのおかげで、私たちは有効で強力なロールモデルを構築することが容易になります。アプリケーションは、より良い開発、テスト、管理、メンテナンスになるように。
キーコンセプト
表1-2の各層が閉じていることに留意されたいです。この階層化アーキテクチャは、非常に重要な機能です。これは層によって転写層を要求しなければならないことを意味します。例えば、要求は、プレゼンテーション層最初のビジネスレイヤに渡され、その後、永続層に伝達され、最終的にデータ層に転写されるに渡されます。
なぜデータ層への直接アクセスを許可していない、それをレイヤー。データのみ、プレゼンテーション層は、直接データ層、はるかに高速経由に比べてデータを取得するために層ごとにアクセスした場合と読みが得られます。隔離層：これは概念を含んでいます。
アーキテクチャの変更された絶縁層が他の層に影響を与えない層：これらの変更は、現在のレベルに制限範囲に影響を与えます。プレゼンテーション層は、直接SQLが変化した場合に永続性、永続層にアクセスすることができ、これはビジネス層とプレゼンテーション層に一定の影響力を持っている場合。アプリケーションは、密結合、コンポーネント間の相互依存関係になります。このアーキテクチャは、維持することは非常に困難になります。
別の態様では、層の間に独立している積層絶縁、各レイヤアーキテクチャほとんど相互理解から。この概念Niubiの場所を説明するために、JSF JSPへのプレゼンテーション層から、スーパー復興を想像してみてください。プレゼンテーション層と一貫したサービス層のサービス層の仮定との間のリンクは、プレゼンテーション層で使用されるとインタフェースアーキテクチャは完全に独立している再構成の影響を受けません。
しかし、閉鎖アーキテクチャレベルも不便があり、時には特定のレベルを開くべきです。あなたは、共有サービス層を追加するために、ビジネスのコンポーネントによって呼び出されるいくつかの一般的なサービス・コンポーネント・アーキテクチャを含めたい場合。アーキテクチャ的には、それは（もプレゼンテーション層にアクセスすることを許可されていない）共有サービスアクセスのビジネス層を制限するため、この例では、サービス層は、通常は良いアイデアです作成します。何の隔離層が存在しない場合は、任意の一般的なサービス・アクセス・レイヤーの可視性を制限する一切のフレームワークが存在しない、それは著作権管理することは困難です。
この例では、新しいサービスはレイヤーで、プレゼンテーション層のコンポーネントは、直接ビジネス層下のサービス層にアクセスすることはできませんです。しかし、今、ビジネス層だけでなく、永続化層を介してサービスへのアクセスも不合理である、層に。これは階層化アーキテクチャの古い問題であり、解決策は、層の一部を開くことです。今オープンの表1-3サービスレイヤに示されるように。要求は、この層をバイパスすることができ、この層は直接、下地層にアクセスします。それは、オープンサービス層であるので、ビジネス層は、サービス層、データの永続化層への直接アクセスを回避することができます。これは非常に合理的です。
建築層とフロー要求との間の関係を決定するために開閉層の概念および設計者および開発者に様々な層におけるアーキテクチャを理解するのに必要な情報とアクセス制限を提供します。アーキテクチャのカジュアル開いたり閉じ層は、プロジェクト全体を緊密に結合されている可能性がある場合は、混乱。後は、テスト維持し、展開することは困難です。
例
階層化アーキテクチャは、それがどのように動作するかで実証し、そのような表1-4のような場面を想像するには、ユーザーが顧客情報へのアクセス要求を送信します。黒の矢印はユーザデータがデータベース要求フローから得られる、赤矢印はユーザデータのリターン・フローの方向を示しています。この例では、顧客の注文データからユーザ情報及びアレイ（顧客注文）。
ユーザーインターフェースは、単純にリクエストして表示顧客情報を受け入れます。データが得られるかは問題で、またはそれらは、データテーブルを使用してどのようなデータ持っていることはありません。ユーザーインターフェースは、顧客情報を検索するための要求を受信した場合、それはユーザーデリゲート（顧客の委任）モジュールに要求を転送します。このモジュールは、対応するデータ（制約）を処理するために対応するサービスレイヤモジュールに見出すことができます。顧客オブジェクト内のビジネス層は、サービス要求（この場合のアクセス顧客情報）のために必要なすべての情報を集約します。このモジュールは、顧客情報を取得する情報を取得するためのDAOの順序を呼び出すための顧客DAOの永続化層を呼び出します。これらのモジュールは、ビジネス層に対応するデータを返す、SQL文を実行します。顧客オブジェクトは、データを受信すると、それはその後、重合顧客デリゲートにデータを転送し、ユーザの目の前に表示される顧客の画面にデータを渡します。
从技术的角度来说，有很多的方式能够实现这些模块。比如说在Java平台中，customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate 查询。Microsoft平台上，customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块，用ADO来实现用户和订单数据的访问模块。
注意事项
分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构，分层架构是再好不过的了。然后，从架构的角度上来说，选择这个模式还要考虑很多的东西。
第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
在这个模式中，请求流只是简单的穿过层次，不留一点云彩，或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。
每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操作。然而，如果这个比例反过来，大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离，项目会变得难以控制。
模式分析
下面的的表里分析了分层架构的各个方面。
整体灵活性
評価：低
分析：総合柔軟性が環境の変化に対応する能力です。それらから単離することができ、階層モードでの変化にもかかわらず、私は、このアーキテクチャの一部も変更すると時間がかかるされてやりたいです。コンポーネント間の重いと密結合は、多くの場合、階層モデルは、柔軟性の低下を引き起こすものです。
展開の容易
評価：低
分析：それはあなたがこのモードを公開どのように大きなプロジェクトに依存して、出版社は、多くの問題かもしれ特にそう。ほとんど変化つの構成要素は、プログラム全体（またはプログラムのほとんど）のリリースに影響を与える可能性があります。出版物は、非業務時間中または週末に公開する計画に従わなければなりません。したがって。成層モードは、アプリケーションのリリースが滑らかでない原因のリリースに柔軟性を低減します。
テスト容易性
評価：高い
分析：コンポーネントがその階層にあるので、他の層をシミュレートする、または直接層を除去することができ、階層モデルをテストするのは簡単です。あなたは孤立ビジネス・コンポーネントをテストし、単一ディスプレイアセンブリをシミュレートすることができます。また、表示機能をテストするために、ビジネス層をシミュレートすることができます。
演奏
評価：低
分析：いくつかの階層化アーキテクチャのパフォーマンスにもかかわらず、本当に良かったが、このモデルの特徴は、それが、高いパフォーマンスをもたらすために発生します。不必要な多くの作業をやって、アーキテクチャのすべての層を横断するサービス要求のため。
柔軟性
評価：低
分析：階層化アーキテクチャの開発プログラムを拡大するのがより困難であるとの開発で、この密結合モードの動向、規模が比較的大きいため。あなたは、階層化アーキテクチャを拡張するために複数のノードに物理的に別のモジュールまたは単に全体のプログラムに分け、全体的な関係が近すぎる、拡大することが困難にされ、各レイヤと考えることができます。
開発のしやすさ
評価：簡単
分析：上記、階層化アーキテクチャの開発の難易度が比較的高いスコアとなっています。このアーキテクチャでは、私たちのすべてに精通しているので、達成することは難しいことではありません。開発プロジェクトではほとんどの企業が技術的な層によって区別され、ほとんどの商業プロジェクト開発のためのこのモデルは非常に適切です。「コンウェイの法則」と呼ば企業の組織構造とそのソフトウェアアーキテクチャの間のリンク。あなたはそれをGoogleとこの興味深いリンクを調べることができます。