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

■プレゼンテーション層

　この層では、利用者とアプリケーションとのやり取りを実装する。含まれるコンポーネントの種類は以下のとおりである。

• UIコンポーネント：利用者とアプリケーションとのやり取りを直接担当するコンポーネント。ユーザーからの入力を受け取ってアプリケーションに渡したり、アプリケーションの処理結果をユーザーに出力したりする。GUI（＝グラフィカル・ユーザー・インターフェイス）においては画面とほぼ同義である。UI（＝ユーザー・インターフェイス）の実装技術に依存するロジックは、このコンポーネントに集約される。

• UIプロセス・コンポーネント：利用者とアプリケーションの一連のやり取りに一定のルールがある場合、そのルールに関する処理を担当するコンポーネント。例えばUIの状態遷移をカプセル化し、状態遷移ロジックを再利用できるようにするなどの利用法が考えられる。従って、このコンポーネントはUIの実装技術に依存しないようにするとよい。

　プレゼンテーション層の設計手順として提案されているのは以下である。

• 要件や制約を満たすクライアントの種類を決定する：デスクトップ・アプリケーションにするのか、Webアプリケーションにするのか、など。

• 表示するデータの形式を決定する：データの表示フォーマットや、表示する際の画面コントロールの大まかな選択など。

• 入力値検証の方針を決定する：どのような検証ロジックにするかなど。

• 呼び出すビジネス・ロジックを決定する：実行するべきビジネス・ロジックを洗い出し、プレゼンテーション層から分離する準備をする。

• ほかのレイヤの呼び出し方を決定する：データ・アクセス層の呼び出しを許可するか、ビジネス層の呼び出しは同期／非同期のどちらにするか、など。

　全体的な推奨事項は以下である。

• 適切なUI技術を選択すべし。

• 画面デザインや画面遷移などの設計規約があるなら守るべし。

• 利用者を中心においたUI設計をすべし。

　ユーザビリティを含むユーザー体験はこの層によるところが多いため、一貫性があり、実際の利用者に違和感のないようなUIにするべきだということである。

　最後に、アーキテクチャ・フレームの概要を説明する。

• キャッシュ：データ参照にキャッシュを活用し、ネットワーク通信を減らすことで、アプリケーションのパフォーマンスやUIの応答性を高められる。

• 実行時結合：独立性の高い画面部品を実行時に結合することで、開発生産性や保守性が高くなる場合がある。互いの依存性をなくすことで、修正時の影響を局所化し、変更したモジュールだけ再ビルド、再配置すればよくなる。

• 例外管理：例外管理機能を集約し、例外のキャッチやスローに一貫性を持たせる。論理階層（レイヤ）や物理階層（ティア）をまたがった例外の伝播（でんぱ）に特に注意を払う。未処理例外が発生してもアプリケーションが安全に終了するようにし、スタック・トレースなどの内部情報を利用者に見せないようにする。

• 入力：利用者の入力手段を適切に選択し、ユーザビリティを高める。標準規約が存在するのであれば、それに従う。

• 画面レイアウト：レイアウト情報はUIコンポーネントやUIプロセス・コンポーネントから分離させる。デザイナーと協調して開発する場合は、ソース・コードがなくてもデザインできるようにする。

• 画面遷移：画面遷移情報はUIコンポーネントやUIプロセス・コンポーネントから分離させる。画面遷移の方法は一貫性を持たせ、利用者の混乱を防ぐ。

• プレゼンテーション・エンティティ：プレゼンテーション層に依存する形式でデータを保持する。ビジネス・ロジックは実装しないが、データの検証ロジックはここに実装してよい。必要がなければ使わなくてよい。

• 要求処理：応答性、保守性、テスト容易性を意識して要求処理を設計する。GUIの場合はUIスレッドを止めないように、処理はバックグラウンド・スレッドで実行する。

• ユーザー体験：設計の段階からユーザビリティを作り込む。利用シナリオが明確に表現されたUIを設計する。利用者にアプリケーションの制御権を与える。

• UIコンポーネント：なるべく標準のコントロールを使うことで、一貫性のあるUIを利用者に提供する。カスタム・コントロールは、特別なデータ入出力が必要なところのみに使う。

• UIプロセス・コンポーネント：プレゼンテーション層で、ビジネス・ロジック以外に複雑な処理を必要とするときにだけ使う。

• 入力値検証：すべての入力値は適切に検証されなければならない。応答性を高めるためにクライアント側でも検証するが、必ずサーバ側でも検証する。

■サービス層

　この層では、信頼境界をまたいだ外部システムまたはクライアント・アプリケーションに対するメッセージ・ベースの通信インターフェイスを実装する。含まれるコンポーネントの種類は以下のとおりである。

• サービス・インターフェイス：信頼境界外とのやり取りを担当する。どういう要求メッセージを受け取り、どのようなビジネス・ロジックを実行し、その結果どういう応答メッセージを返すかを定義した「契約」を遂行することに責任を持つ。

• メッセージ・タイプ：サービス・インターフェイスが送受信するメッセージの型を表現する。サービスが受け取る要求メッセージには、サービスに対する処理命令と、その処理に使われるデータの両方が格納される。あるサービス呼び出しの要求や応答にどんなメッセージ・タイプが用いられるかも「契約」の一部である。

　サービス層の設計手順として提案されているのは以下である。

• データとメッセージの契約を定義する：すなわち、メッセージのスキーマを最初に決定する。

• サービスの契約を定義する：続いて、サービスとして公開するビジネス処理を決定する。

• 失敗時の契約を定義する：呼び出し元に渡すエラー情報の形式を決定する。

• データ変換を設計する：ビジネス・エンティティとデータ契約との対応付け方針を決定する。

• 抽象化を検討する：ビジネス層とのやり取りを抽象化し、疎結合にする。

　全体的な推奨事項は以下である。

• ビジネスの粒度ではなく、アプリケーションの粒度にするべし

• データ契約は拡張可能にするべし

• データは標準的な要素の組み合わせとするべし

• クライアントの実装に依存するべからず

• サービス契約に忠実に実装するべし

• 不正な入力があり得ることを前提にするべし

• 機能要件のロジックと非機能要件のロジックは分離するべし

• 要求の再送に対応し、べき等性（＝何度行っても結果が同じになること）を保証するべし

• 要求順の入れ替わりに対応し、交換可能性を保証するべし

• 契約のバージョンを考慮するべし

　疎結合かつ高粒度にすることが、サービスの安定性を高めるための推奨事項である。

　最後に、アーキテクチャ・フレームの概要を説明する。

• 認証：信頼境界をまたぐため、適切な機構による認証は必須である。

• 承認（認可）：URLやメソッド単位でアクセス許可を割り当てる。サービスの実行権限は最小にしておく。

• 通信：要件に合わせてプロトコルを選択する。非同期通信や双方向通信の必要性も検討する。

• 例外管理：未処理の例外でサービスが停止しないようにする。また、例外によって内部情報を公開してしまわないようにする。

• メッセージ・チャネル：通信プロトコルを抽象化する機構を検討する。

• メッセージ作成：メッセージ型を適切に設計し、それに従ってメッセージを構築する。

• メッセージ・エンドポイント：メッセージ交換の口としての非機能的な要件を満たすよう、設計／実装しなければならない。

• メッセージ保護：通信プロトコルでセキュリティを確保する方式と、メッセージでセキュリティを確保する方式を使い分ける。

• メッセージ・ルーティング：サービス層のロジックを抽象化し疎結合にすることに利用できる。

• メッセージ変換：メッセージング基盤に対するアダプタや、メタデータを活用したデータ型変換を検討する。

• REST：RESTとは「表現可能な状態の転送」（REpresentational State Transfer）を表す。サービスが管理するリソースと、そのリソースの状態とをまとめて一意なURIを割り当てるアーキテクチャ・スタイルである。送受信されるデータ・フォーマットには、JSONやATOMや単なるXMLがよく用いられる。

• SOAP：XMLをベースにした拡張可能なメッセージ交換プロトコルであり、さまざまな標準仕様がSOAPの上に規定されている。仕様の全体像は複雑だが、相互運用性はよく検証されており、.NETやJavaなどではライブラリやツールがよく整備されている。

　続いて、ビジネス層とデータ・アクセス層について説明する。

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

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

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