連載:アプリケーション・アーキテクチャ・ガイド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解説」


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メールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH