連載 アプリケーション・アーキテクチャ設計入門 第1回　.NET開発者のための設計ガイドライン 日本ユニシス　猪股 健太郎 2003/08/16

---

論理アーキテクチャの全体像

　似たような役割を持つコンポーネントが論理階層（レイヤ）にグループ化され積み重ねられた階層型分散アプリケーションについては、前ページの「階層型分散アプリケーション」で簡単にまとめたとおりである。分散アプリケーションにおいて、アプリケーションをプレゼンテーション層、ビジネス層およびデータ層に分割することの利点は広く受け入れられている。

　AAfN本文では、このような階層構造はサービスにも適用されるとしている。論理的に高位の視点から見れば、サービス指向のソリューションは、メッセージを交換する複数のサービスから構成される。サービスの内部を見てみれば、各サービスは、プレゼンテーション層、ビジネス層およびデータ層にグループ化された複数のコンポーネントから構成されている。

　ここで重要なことは、（1）サービスは疎に結合していること、（2）サービスはそれぞれのデータソース、ビジネス・ロジック、ユーザー・インターフェイスを持つこと、（3）ただし、ユーザー・インターフェイスを持たず、データソースとビジネス・ロジックからなるサービスもあること、（4）サービスはそれぞれのデータを隠ぺいし、データソースに関連するトランザクションは単独で完結すること、この4つである。

　さて、アプリケーションおよびサービスをプレゼンテーション層、ビジネス層およびデータ層に分割することについて説明したが、このような階層構造にうまく適合しないコンポーネントもある。それは、セキュリティ、運用管理、通信のポリシーである。

　分散ソリューションは複数の組織や複数の物理階層（ティア）から構成される場合もある。各部分において、セキュリティ、運用管理、通信などのポリシーが異なる場合もあり得る。そのようなポリシーが、アプリケーションやサービスがどのように配置され、どのように通信するのかを定めるルールを決定するので、ポリシーはアプリケーション全体、またはポリシー同士に影響を及ぼす。

　以上の考察を基に提示された論理アーキテクチャが下図である。アプリケーションおよびサービスは、プレゼンテーション層、ビジネス層、データ層の論理階層（レイヤ）に分類されたコンポーネント群と、論理階層（レイヤ）をまたがる形で配置されたコンポーネント群から構成されている。

Application Architecture for .NETで推奨されている論理アーキテクチャ

アプリケーションおよびサービスは、プレゼンテーション層、ビジネス層、データ層の論理階層（レイヤ）に分類されたコンポーネント群と、論理階層（レイヤ）をまたがる形で配置されたコンポーネント群（通信、運用管理、セキュリティ）から構成されている。

　これは、AAfNで推奨されている論理アーキテクチャである。実際の開発では、このアーキテクチャを基に論理アーキテクチャを設計するとよい。その際のポイントは、以下の6つである。

アプリケーションにどのようなコンポーネントが必要とされるか明確にする。

　AAAfNではコンポーネントを8＋3種類に分類している（上図参照）が、必ずしもすべてを使う必要はない。アプリケーションあるいはサービスによっては、一部のコンポーネントは不要になる場合もある。

1つ、あるいは少数の設計モデルに従い、矛盾のないコンポーネント設計にする。

　これは、設計および実装の追跡性を上げ、保守しやすくするためである。

物理的な配置を考える前にコンポーネント同士の通信手段について考慮する。

　リモート通信のインターフェイスは粒度を大きくして疎結合にすることなどを指している。

データ交換のフォーマットはアプリケーションあるいはサービスの内部で一貫性を持たせる。

　1つのアプリケーションあるいはサービスで、多数のデータ・フォーマットをまぜこぜに使うのは、実装を困難にし、拡張性や保守性を犠牲にする。

セキュリティ／運用管理／通信のポリシーを適用するコードはビジネス・ロジックから可能な限り切り離す。

　これらのポリシーは後に変更される可能性がある。ポリシーを参照するコードはビジネス・ロジックに埋め込んでしまうのではなく、カスタム属性やAPIを活用すること。

どのような論理階層（レイヤ）で構成するかを最初に考える。

　POSA本（Pattern-Oriented Sofware Architecture）のLayersアーキテクチャ・パターンを厳密に適用し、下位の論理階層（レイヤ）のうち隣接するものだけ呼び出すようにする場合もあるだろうし、下位の論理階層（レイヤ）であればすべてを呼び出せるようにする、いわゆる“Relaxed Layers”にする場合もあるだろう。重要なのは、最初に方針を立てて、その後はそれに従うことだ。

　では次章から、それぞれのコンポーネントの特徴について簡単に説明しよう。

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第1回　.NET開発者のための設計ガイドライン
	1．アーキテクチャの重要性と参照アーキテクチャ
	2．Application Architecture for .NETの概略
	3．論理アーキテクチャの全体像
	4．論理アーキテクチャを構成するコンポーネント群

　

「アプリケーション・アーキテクチャ設計入門」

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