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

---

論理アーキテクチャを構成するコンポーネント群

―　プレゼンテーション層　―

ユーザー・インターフェイス・コンポーネント

　ユーザー・インターフェイス・コンポーネントは、ユーザーとアプリケーションとがやりとりする手段を提供する。

　小売業アプリケーションの例で考えてみよう。Webサイトは顧客に対し商品を見せる機能と顧客からの注文を受け付ける機能を持っている。また、営業担当用のWindowsアプリケーションは顧客が電話で伝えた注文データを入力するためのフォームを備えている。

　ユーザー・インターフェイス・コンポーネントを実装する際は、WindowsフォームやWebフォームなどをはじめとした、データを描画・フォーマットする技術、およびデータを受け取って検証する技術が用いられる。

ユーザー・プロセス・コンポーネント

　ユーザーとシステムとのやりとりは一定のプロセスに従う。

　小売業アプリケーションなら、商品データを見るためのプロセスはこんなふうに実装されるかもしれない。まず、商品カテゴリの一覧からカテゴリを選ぶ。次に、そのカテゴリに属する商品の一覧から個々の商品を選ぶ。その結果、選んだ商品の詳細を見ることができる。同様に、商品を購入するときであれば、情報をユーザーから集めるためのプロセスが存在するはずだ。以下はその一例である。まず買いたい商品の詳細情報を入力させる。商品の種類はすでに選択されているはずなので、色のバリエーションや、個数などが対象になる。次に、支払いの詳細を入力させる。クレジットカードの情報、ローンの有無などである。そして最後に配達の詳細を入力させる。届け先、配達日時などである。

　このようなユーザーとの複数のインタラクションを制御する機能は、単一のインタラクションしか担当しないユーザー・インターフェイスのコードに埋め込むのではなく、独立したコンポーネントとして用意した方がよい。そうすることでこの機能をさまざまなユーザー・インターフェイスで共通に使うことができる。

―　ビジネス層　―

サービス・インターフェイス

　ビジネス・ロジックをサービスとして外部に公開する場合、ビジネス・ロジックに直接関係しないさまざまな機能が必要となる。サービスの利用者が複数いて、利用者ごとに通信の規約（トランスポート、フォーマット、プロトコル、セキュリティ、例外など）が違ってくる場合もある。そのような各種規約に対応する機能をビジネス・コンポーネントから独立させたものがサービス・インターフェイスだ。

　例えば、クレジットカードの与信サービスは、サービスが提供する機能と呼び出しの方法についての定義を公開し、その定義に合ったサービス・インターフェイスを公開する必要がある。

ビジネス・ワークフロー

　ユーザー・プロセス・コンポーネントが集めたデータはビジネス・プロセスを実行するために使われる。小売業アプリケーションの例を挙げると、支払いの詳細が送信されて、配達の詳細が送信されたなら、システムは代金を受け取るプロセスや配達を手配するプロセスの実行を開始するだろう。

　そのようなビジネス・プロセスは複数のステップからできていて、各ステップは順序正しく実行される必要がある。小売業アプリケーションであれば、「注文の合計金額を計算する」「クレジットカードの与信を行う」「支払いを処理する」「配達の手配をする」といったステップが必要だろう。

　また、ビジネス・プロセスの各ステップには長い時間がかかるものもあるので、ビジネス・プロセスが完了するのがいつになるかは事前に知ることはできない。だから要求されたタスクや処理すべきデータはきちんと管理されなければならない。ビジネス・ワークフローは、そのような長期に及ぶ多ステップのビジネス・プロセスを定義・調整するためのものだ。このようなコンポーネントは、BizTalk ServerオーケストレーションのようなBPM（Business Process Management）ツールを使うと楽に実装できる。

ビジネス・コンポーネント

　ビジネス・プロセスがワークフローで制御されるような大規模なものであっても、1つのステップしかない小規模なものであっても、アプリケーションにはビジネス・ルールを実装してビジネス・タスクを実行するコンポーネントが当然必要だ。ということで、アプリケーションのビジネス・ロジックを実装するのがビジネス・コンポーネントである。

　相変わらず小売業アプリケーションを引き合いに出せば、「注文の合計金額を計算して適切な運送料を加える」といったたぐいのロジックを実装する必要があるだろう。

ビジネス・エンティティ・コンポーネント

　ほとんどのアプリケーションでは、コンポーネント間でデータをやりとりしなければならない。例えば小売業アプリケーションでは、商品のリストをユーザーに表示するために、商品リストをデータアクセス・ロジック・コンポーネントからユーザー・インターフェイス・コンポーネントまで引き渡さなければならない。ビジネス・エンティティ・コンポーネントとは、商品や注文などのように、実世界に存在する概念（＝エンティティ）を表現するデータだ。

　アプリケーション内部で使われるビジネス・エンティティ・コンポーネントは、DataSet、DataReader、XMLストリームといったデータ構造で実装されることもあれば、エンティティを表現するオブジェクト指向のクラスで実装されることもある。

―　データ層　―

データアクセス・ロジック・コンポーネント

　ほとんどのアプリケーションやサービスはどこかのタイミングでデータソースにアクセスするだろう。小売業アプリケーションであれば、商品詳細をユーザーに表示するためにデータベースから商品データを取得する必要があるし、ユーザーが商品を発注したときにはデータベースに注文詳細を挿入する必要がある。

　データアクセス・ロジック・コンポーネントは、データへのアクセスを別の論理階層（レイヤ）に分割することで、データアクセスのロジックを抽象化する。これにより、データアクセスのロジックを一カ所に集中化でき、設定や管理のコストを軽減することができる。

サービス・エージェント

　ビジネス・コンポーネントがアプリケーション外部のサービスを使う必要が生じた場合、そのサービスと会話するためのプロトコルを実装するコードが必要になるだろう。サービス・エージェントは外部サービス固有のプロトコル（アプリケーション・プロトコル）を隠ぺいし、外部サービスを抽象化するためのものだ。サービス・エージェントを独立させれば、別のサービスを追加することも容易になる。

　小売業アプリケーションのビジネス・コンポーネントであれば、クレジットカードの与信サービスと接続するサービス・エージェントと、宅配便サービスと接続するサービス・エージェントの2種類が必要になる。

―　その他　―

セキュリティ、運用管理、通信ポリシーのためのコンポーネント群

　アプリケーションは、例外を管理するコンポーネントや、ユーザーを認証するコンポーネントや、ほかのサービスやアプリケーションと通信するコンポーネントなども使用する。これらのような、アプリケーションのすべての層で利用されるコンポーネント群は、無理に論理階層（レイヤ）の構造に入れてしまわずに、階層構造の外側に置くこととする。

まとめ

　今回は、AAfN（Application Architecture for .NET）の導入部と、提示されている論理アーキテクチャについて紹介した。次回は、各コンポーネントの具体的な実装方法を見ていきたい。

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

　

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

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