階層化
在分解复杂的软件系统时，软件设计者用的最多的技术之一就是分层。在计算机本身的架构中，可以看到：到处都有分层的例子：不同的层从包含了操作系统调用的程序设计语言，到设备驱动程序和CPU指令集，再到芯片内部的各种逻辑门。网络互联中，FTP层架构在TCP层之上，TCP架构在IP之上，IP又架构在以太网之上。
当用分层的观点来考虑系统时，可以将各个子系统想象成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。因此，第4层使用第三层的服务，第3层使用第二层的服务，第4层无需知道第二层的细节。（当然，并非所有的分层架构都这么隔绝，但绝大多数是不透明的。）
将系统按层次分解有很多重要的好处
-
他のレベルをあまり理解しなくても、特定のレイヤーを有機的な全体として理解することができます。たとえば、イーサネットの動作の詳細を知らなくても、TCP上でFTPサービスを構築できます。
-
特定のレイヤーの特定の実装は、前後に提供されるサービスが同じである限り、置き換えることができます。たとえば、FTPサービスは、イーサネット、PPP、またはネットワークオペレーターが使用するネットワーク上にあるかどうかに関係なく変更する必要はなく、伝送ケーブルを提供するネットワークオペレーターとは関係ありません。
-
レベル間の依存関係を最小限に抑えることができます。ネットワークオペレータが物理的な伝送システムを変更したが、IP層が同じである限り、FTPサービスは変更されないままであると仮定します。
-
階層化は標準化作業に役立ちます。TCPとIPは、さまざまなレベルがどのように機能するかに関する標準です。
-
特定のレベルが構築されると、それを使用して多くの上位レベルのサービスをサポートできます。したがって、TCP / IPは、FTP、telnet、SSH、およびHTTPによって同時に使用されます。それ以外の場合、これらすべての高レベルプロトコルは、それぞれの低レベルプロトコルを作成する必要があります。
分层是一种重要的技术，但也有缺陷： -
階層はすべてをカプセル化するわけではありません。時々それは私たちに連鎖的な変化をもたらします。最も典型的な例は、階層設計のエンタープライズアプリケーションです。ユーザーインターフェイスに表示されるデータフィールドを追加する場合は、データベースに対応するフィールドを追加する必要があります。また、ユーザーインターフェイスとデータベースの間に各フィールドを追加する必要があります。 。レイヤーに対応する変更を加えます。
-
レベルが多すぎるとパフォーマンスに影響します。各レベルでは、一般に、ある形式の表現から別の形式への移行があります。
エンタープライズアプリケーションのレベルの進化
初期のバッチ処理である単一ファイルは、階層を必要としません。
1990年代のクライアント/サーバーシステムの出現により、階層化の概念がより明らかになりました。このようなシステムは2レベルのシステムです。クライアントにはユーザーインターフェイスとその他のアプリケーションコードが含まれ、サーバーは通常リレーショナルデータベースです。VB、PowerBuilder、Delphiなどの一般的なクライアントツール。これらのツールを使用すると、データ集約型のアプリケーションを非常に簡単に構築できます。ユーザーインターフェイスコントロールは通常SQL対応であるためです。したがって、コントロールを「デザイン領域」にドラッグしてインターフェイスを作成し、プロパティシートを使用してコントロールをバックエンドデータベースに接続できます。
アプリケーションにリレーショナルデータの単純な表示と変更のみが含まれている場合、このクライアント/サーバーシステムは非常にうまく機能します。問題は、ビジネスルール、検証、計算などのドメインロジックに起因します。通常、人々はクライアント側でそれらを記述しますが、これは非常に不器用であり、多くの場合、ドメインロジックをユーザーインターフェイスに直接埋め込みます。ドメインロジックがより複雑になるにつれて、これらのコードはますます使いにくくなります。さらに、この方法で冗長コードを生成するのは簡単です。つまり、簡単な変更で、多くのインターフェイスで同様のコードを見つけることができます。
もう1つの方法は、これらのロジックをストアドプロシージャとしてデータベース側に配置することです。ただし、ストアドプロシージャは限られた構造化メカニズムしか提供しないため、コードが不器用になります。さらに、リレーショナルデータベースが好きな理由の1つは、SQLがデータベースベンダーの変更を可能にする標準であるということです。ストアドプロシージャはデータベースベンダー専用であるため、データベースベンダーを交換するための追加コストが高すぎます。
クライアント/サーバーアプローチがますます普及する一方で、オブジェクト指向アプローチが台頭し始めています。オブジェクト指向は、ドメインロジックの問題に対する答えを見つけました。3層アーキテクチャシステムに目を向けます。このように、ユーザーインターフェイスはプレゼンテーション層に実装され、ドメインロジックはドメイン層に実装され、データはデータベース層に格納されます。このメソッドを使用すると、コードインターフェイスから複雑なドメインロジックを抽出し、それを個別に中間層に配置し、オブジェクトを使用してモデル化および整理できます。