連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第4回 論理階層とコンポーネントに分解したアプリケーション・アーキテクチャ 日本ユニシス　猪股 健太郎 2009/08/18

Page1 Page2 Page3

　連載第4回目となる今回は、アプリケーション・アーキテクチャ・ガイド（以下、AAG）で定義されている論理階層と、その中に含まれるコンポーネントについて説明していく。

　なお、AAG本文においては「レイヤ（Layer）」と「ティア（Tier）」を使い分けている。前者はコンポーネントの役割に応じたアプリケーション・ロジックの論理的な階層構造を、後者はアプリケーション・ロジックを異なるコンピュータに分散して配置し、それらがネットワーク越しに通信することでアプリケーションとして動作するようにした際の、ネットワーク的な階層を指している。本稿ではそれぞれを、「論理階層（レイヤ）」と「物理階層（ティア）」と表記する。

■AAGで定義される論理階層（レイヤ）

　旧版となる「.NETのアプリケーション・アーキテクチャ」（以下、AAfN）でも、アプリケーションを論理階層とコンポーネントに分解した論理アーキテクチャが定義されていた（「アプリケーション・アーキテクチャ設計入門　第1回　.NET開発者のための設計ガイドラインを参照）。AAGで定義される論理アーキテクチャはその発展形である。

　AAGでは、論理階層（レイヤ）が1つ加わっており、コンポーネントもいくつか追加されている。それが下の図である。

AAGの論理アーキテクチャ

　各論理階層（レイヤ）を簡単に紹介しよう。

• プレゼンテーション層：利用者とアプリケーションのやり取りを実装する論理階層（レイヤ）。アプリケーションを対話的に操作するような使い方がない場合では、プレゼンテーション層が不要なケースもある。

• サービス層：信頼境界をまたいだ外部システムまたはクライアント・アプリケーションに対するメッセージ・ベースの通信インターフェイスを実装する論理階層（レイヤ）。アプリケーションのビジネス・ロジックが外部から呼び出される場合は仲介となるが、そのような呼び出しが存在しない場合では、サービス層が不要なケースもある。

• ビジネス層：システムの中心となるビジネス・ロジックを実装する論理階層（レイヤ）。トランザクションの管理もここで行う。ビジネス・ロジックがないアプリケーションの場合では、ビジネス層が不要なケースもある（もしそのようなアプリケーションが存在するのなら）。

• データ・アクセス層：データソースのデータにアクセスするためのロジックを実装する論理階層（レイヤ）。データソースは、RDBMS（リレーショナル・データベース管理システム）のようなデータベース・システムの場合もあるし、外部システムが提供するサービスの場合もある。

　これら4つの論理階層（レイヤ）に加えて、さまざまな論理階層（レイヤ）から呼び出される可能性のある、階層横断的なコンポーネントも定義されている。

• セキュリティに関するコンポーネント：認証、承認（認可）、入力値検証などを担当する。

• 運用管理に関するコンポーネント：例外管理、ログとトレース、パフォーマンス監視、構成情報管理などを担当する。

• 通信に関するコンポーネント：メッセージ・ベースの疎結合通信（＝ほかのサービスやアプリケーションとの通信）や、プラットフォームを限定した密結合通信（＝アプリケーション内部の通信）について、プロトコルやポリシーなどを担当する。

　AAfNの論理階層とAAGの論理階層を比べると、サービス層が追加されていることにすぐ気が付く。AAfNではビジネス層に含められていたのだが、AAGでは独立した論理階層になっているのだ。

　サービス層が独立した理由だが、サービスが以前よりも重要になってきたためと筆者は考える。これはどういうことかというと、AAfNが書かれた2002年と比べて、メッセージ交換による通信が、利用頻度の面でも、実装技術のバラエティという面でも増えているということだ。

　AAfNのころは、メッセージ交換による通信はSOAPによるXML Webサービスが重要だった。外部システムに対するサービス公開といえば業務システムの連携だったし、アプリケーション内部に対するサービス公開といえば「スマート・クライアント」に代表される賢いクライアントからのビジネス・ロジック呼び出しだった。AAfNでは、前者についてはMSMQによる非同期通信も考慮しつつ、全体的にはSOAPを推奨していたように感じる。

　ところが最近ではSOAPを使わないサービスが増えているのだ。外部システムに対するサービス公開では、Web APIによるマッシュアップが流行している。また、アプリケーション内部に対するサービス公開については、いわゆるRIA（リッチ・インターネット・アプリケーション）がHTTP通信を介してビジネス・ロジックを呼び出したりデータを取得したりするようになってきた。どちらのケースも、SOAP以外の選択肢として、REST（＝Representational State Transfer：シンプルな呼び出し形式のWebサービス）／JSON（＝JavaScript Object Notation：JavaScriptで取り扱いやすい形式のデータ）／POX（＝Plain Old XML：シンプルで基本的なXMLデータ）といった技術が使われることが多い。

　そのような利用技術の変化を踏まえて、AAGでは新たにサービス層が定義されることになったのだと筆者は理解している。

■論理階層（レイヤ）と物理階層（ティア）の選択

　これらの各論理階層（レイヤ）の中身を解説する前に、アプリケーションをどのように論理階層（レイヤ）に分割するべきか、そして、アプリケーションをどのように物理階層（ティア）に分散配置するべきかについての原則を記しておく。

　論理階層（レイヤ）と物理階層（ティア）の原則は、AAfNにおいてもAAGにおいても変わりはない。すなわち、必要がなければ分割するな、である。

　理由は2つある。1つ目は、論理的・物理的に分割すればするほどシステムが複雑になるため、そして2つ目は、物理的に分散配置させるとレスポンスが遅くなるためである。誤解しないでほしいのだが、AAGは「絶対に分割するな」といっているわけではない。何のために分割するかを理解し、目的に沿って適切に分割するべきだということなのである。

　アプリケーションを論理階層（レイヤ）に分割する理由として、AAGは以下のものを挙げている。

• ロジックの責務を区別して分割することで、保守性を向上させる：小規模なアプリケーションであれば問題にならないこともあるが、ある程度以上の規模であれば、責務ごとに論理階層（レイヤ）を分け、論理階層（レイヤ）間の依存関係を小さくするとよい。そうすることで、ある論理階層（レイヤ）の実装を変更しても、ほかの論理階層（レイヤ）に影響を与えないようにできる。

• 必要に応じて物理的に分散配置しやすくする：論理階層（レイヤ）間の依存関係が小さければ、そこを境に別の物理階層（ティア）に分割することも行いやすい。AAGでは、サービス層と、非同期的に実行されるビジネス層については、呼び出し元の層とは別の物理階層（ティア）に分けることを提案している。しかし、それ以外の境界については、以下で述べるような理由がなければ同じ物理階層（ティア）に置くべきだとしている。

　アプリケーションを物理階層（ティア）に分割する理由として、AAGは以下のものを挙げている。

• セキュリティに関する要件を満たす：物理階層（ティア）が別れていれば、間にファイアウォールなどの機器を追加しやすい。

• ビジネス・ロジックを共有する：例えばデスクトップ・アプリケーションのビジネス・ロジックをサーバ上に配置して共有することで、運用管理のコストを低減するなどである。

• 複数台のコンピュータで負荷を分散する：アプリケーションの処理負荷に対して、CPUやメモリといったリソースが十分でないことがパフォーマンス上のボトルネックになる場合、複数台のコンピュータに分散配置させた方が、通信のオーバーヘッドを差し引いても結果的に性能が向上することもある。

　論理階層（レイヤ）の概説と、その配置についてはここまでとして、次からは各論理階層（レイヤ）の中身を見ていこう。

　AAGでは10章〜13章に相当する。各章では、論理階層（レイヤ）に含まれるコンポーネントの解説、アーキテクチャ設計の手順、全体的な推奨事項、考慮すべきアーキテクチャ・フレームごとの推奨事項、関連する設計パターン、実装に利用できるテクノロジなどが説明されている。本稿ではそれらのすべてを解説はしないので、詳しく知りたい方はぜひAAG本文をお読みいただきたい。

　プレゼンテーション層、サービス層、ビジネス層、データ・アクセス層の順番で説明する。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第4回 論理階層とコンポーネントに分解したアプリケーション・アーキテクチャ
	1．AAGの論理アーキテクチャ／レイヤとティアの選択
	2．プレゼンテーション層／サービス層
	3．ビジネス層／データ・アクセス層

「アプリケーション・アーキテクチャ・ガイド2.0解説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）