連載

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

第1回 .NET開発者のための設計ガイドライン

日本ユニシス 猪股 健太郎
2003/08/16

Page1 Page2 Page3 Page4

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

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

 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.論理アーキテクチャを構成するコンポーネント群
 
インデックス・ページヘ  「アプリケーション・アーキテクチャ設計入門」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間