連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第2回 アプリケーション概要を定義するには？ 日本ユニシス　猪股 健太郎 2009/06/02
Page1 Page2 Page3

●3. アーキテクチャ・スタイルを選ぶ

　アーキテクチャ・スタイルとは、前回でも述べたとおり、複数のアーキテクチャに共通して見られる設計原則の集合のことである。適切なアーキテクチャ・スタイルを選ぶことで、よくある問題点への解決手段を再利用できるようになる。

　ここでは、8つのアーキテクチャ・スタイルについて、基本的な特徴と、検討する際の基準を述べる。

○クライアント／サーバ型

　クライアントとサーバの両方で構成される分散処理システムのアーキテクチャである。クライアントはユーザーと直接対話する中でサーバに対して要求を出し、その応答を受け取って何らかの処理をし、ユーザーに結果を返す。サーバは原則としてクライアントからの要求を待ち続けており、サーバからクライアントに要求を出すことはない。

　このスタイルの利点として、すべてのデータがサーバに集約されるため、データの管理が簡単になり、セキュリティ上の安全性を高めやすいことと、サーバのメンテナンスが容易なことが挙げられる。

　従って、以下のような場合にはクライアント／サーバ型を検討するとよい。

• クライアント数が多い場合
• ブラウザで実行するWebベースのアプリケーションにする場合
• ビジネス・ロジックを組織外に公開する場合
• データ管理機能を集中化したい場合
• 多種類のクライアントやデバイスに対応する場合

○コンポーネント指向

　システムを、あらかじめ決められたインターフェイスを通じて連携するコンポーネント群に分割するアーキテクチャである。コンポーネントは自身の内部状態や実装の詳細を外部に公開しない。また、ほかのコンポーネントに対する依存関係は極小化される。その結果、コンポーネントの独立性が高くなり、再利用性が高まる。

　このスタイルの利点として、システム全体の複雑さを小さくできること、コンポーネントの置き換えが容易であること、ロジックの再利用が可能なためコストを削減できることが挙げられる。

　従って、以下のような場合にはコンポーネント指向を検討するとよい。

• 適切なコンポーネントを利用できる場合
• データ入力が少なく、手続き的な処理を多く実行する場合
• 比較的単純なシステムで、論理階層を厳密に考えなくてもよい場合
• 複数のプログラム言語で実装された部品を組み合わせる場合
• 機能の一部を簡単に置き換えたり更新したりしたい場合

○論理的多階層

　アプリケーションの関心事を、役割や責任に応じて階層に分けて配置するアーキテクチャである。異なる論理層間のやりとりは、あらかじめ決められたインターフェイスを通じて行われる。複数の論理層を1つの物理層に配置してもいいし、それぞれ別の物理層に配置してもいい。論理層をまたがった呼び出しは、原則として低い階層の1つの論理層に対してのみ許可される。そうすることで、層をまたがった依存関係が1方向に限定され、再利用性が高まる。

　このスタイルの利点として、変更による影響を1つの論理層に限定できること、ある論理層で利用するテクノロジを入れ替えてもシステム全体に影響しないこと、物理層に分散配置が容易なためパフォーマンスを向上させやすいこと、テストが実施しやすいことが挙げられる。

　従って、以下のような場合には論理的多階層を検討するとよい。

• システムが複雑な場合
• 保守性や拡張性を高くしたい場合
• ビジネス・ロジックをサービスとして公開するアプリケーションを持っている場合
• 多種類のクライアントやデバイスに対応する場合
• 複雑なビジネス・ルールやプロセスを実装する場合

○メッセージ・バス

　通信相手に依存せず、あらかじめ定義されたメッセージ（電文）を送受信するシステムのアーキテクチャである。メッセージを送受信する際は、バスと呼ばれる共通の通信チャンネルを用いる。また、メッセージの送受信は非同期的に行われるのが普通である。メッセージの形式は共通のスキーマによって、あらかじめ定義されている。

　このスタイルの利点として、アプリケーションの通信形態が単純になること、パフォーマンスとスケーラビリティを高くできること、アプリケーションの追加・削除が容易なことが挙げられる。

　従って、以下のような場合にはメッセージ・バスを検討するとよい。

• 互いに通信して処理を行うアプリケーションを持っている場合
• 外部のアプリケーションや、異なる実行環境のアプリケーションとやりとりする処理を実装する場合
• 既存アプリケーションの処理を統合して1つにまとめる場合
• 非同期的に処理を実行する場合

○MVC（モデル／ビュー／コントローラ）

　ユーザーとのやりとりに関する処理を、UIの見た目やデータから分離させるアーキテクチャである。モデルはデータを表現し、ビューはUIを表現し、コントローラはユーザー入力を受け取ってモデルに通知する。ビューとコントローラはモデルにのみ依存する。逆に、モデルはビューやコントローラに依存しない。モデルの変更は、一般にオブザーバー・パターンでビューに通知される。それにより、関心事が分離され、テストが実行しやすくなる。

　このスタイルの利点として、再利用性が高いこと、単体テストを実行しやすいこと、依存関係が整理されることでアプリケーションの複雑さが緩和されることが挙げられる。

　従って、以下のような場合にはMVCを検討するとよい。

• UIをテストしやすくし、保守性を高くしたい場合
• UIの見た目と処理とを分離したい場合
• UIの見た目を定義する部分にユーザー操作を処理するロジックを含まない場合
• ユーザー操作を処理するロジックにビジネス・ロジックを含まない場合

○物理的多階層

　システムの機能を階層化し、物理的に別のコンピュータに配置するアーキテクチャである。物理的多階層は、論理的多階層が前提である。

　このスタイルの利点として、スケーラビリティがあること、システムの構成が柔軟になること、可用性が高まることが挙げられる。

　従って、以下のような場合には物理的多階層を検討するとよい。

• セキュリティ・ポリシー上、ビジネス・ロジックをネットワーク的に安全な位置に配置しなければならない場合
• ビジネス・ロジック部分の負荷が高いため、負荷を分散させたい場合

○オブジェクト指向

　アプリケーションの機能を、データと振る舞いを併せ持つオブジェクトに分解し、再利用性を高くしたプログラミング手法によるアーキテクチャである。オブジェクトは異なった役割や責務を持っているが、継承やポリモーフィズムといった機構により抽象化が可能である。そして、アプリケーションが実行するタスクはオブジェクト同士の協調と連携によって実現される。

　このスタイルの利点として、拡張性が高いこと、再利用性が高いこと、人間にとって理解しやすいモデルを構築できることが挙げられる。

　従って、以下のような場合にはオブジェクト指向を検討するとよい。

• 実世界のオブジェクトや行動に基づいてアプリケーションをモデル化したい場合
• 要件や制約を満たすオブジェクトやクラスを持っている場合
• データとロジックを再利用可能な形にカプセル化したい場合

○サービス指向

　機能をサービスとして公開したり、公開されたサービスを利用したりするアーキテクチャである。サービスはメッセージ・ベースの疎結合で連携し、さまざまなプロトコルやフォーマットで通信できる。サービスはスキーマと契約で定義され、自律性を持ち、実行環境にかかわらず相互運用可能である。

　このスタイルの利点として、疎結合により相互運用性を持つこと、業務単位での再利用を実現できることが挙げられる。

　従って、以下のような場合にはサービス指向を検討するとよい。

• 適切なサービスを利用できる場合
• 複数のサービスを1つのUIに統合するアプリケーションを開発する場合
• SaaSやクラウド・ベースのアプリケーションを開発する場合
• アプリケーション内部でメッセージ・ベースの通信に対応する場合
• システムの機能を、実行環境に依存しない形で公開する場合
• 認証など、信頼関係で結ばれたサービスを利用する場合
• ディレクトリ・サービスなどで発見可能なサービスを公開する場合

●4. 採用する技術を決める

　アプリケーション種別、配置方法、アーキテクチャ・スタイルが決まれば、それに伴って採用する技術を限定することができる。そのうえで、残っている非機能要件や、各種制約（組織のITポリシーやITインフラや要員スキルなど）を加味して技術を決定する。

　ここでは、5つのアプリケーション種別に対応する.NETの技術を挙げる。選択基準の詳細については次回以降で説明する。

○モバイル

　.NET Compact Framework、ASP.NETモバイル・コントロール、Silverlightが選択できる。

○クライアント・アプリケーション

　Windowsフォーム、WPF、WindowsフォームとWPFの混合、XBAPが選択できる。

○RIA

　Silverlight、またはSilverlightとAjaxの混合が選択できる。

○Webアプリケーション

　Webフォーム、WebフォームとAjaxの混合、WebフォームとSilverlightの混合、ASP.NET MVC、ASP.NET Dynamic Dataが選択できる。

○サービス

　WCF、またはASP.NET Webサービスが選択できる。

■

　次回は、AAGが推奨するアーキテクチャ設計の5つのステップのうち、「3. ホットスポットの抽出」について詳しく説明する。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第2回 アプリケーション概要を定義するには？
	1．アーキテクチャ設計とは
	2．アプリケーション種別を決定する／配置シナリオを検討する
	3．アーキテクチャ・スタイルを選ぶ／採用する技術を決める

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

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