AAG2.0 アーキテクチャ スタイル
2012-07-16 14:27:12
一覧
クライアント／サーバー型
クライアント／サーバー ソフトウェア アーキテクチャモデルはクライアントシステムとサーバーシステムに分けられ、両者はネットワーク越しに通信する。 クライアント／サーバーアプリケーションは、クライアントとサーバーの両方で構成される分散処理システムである。 サーバーがクライアントからの要求を待っている間にクライアントが通信を開始する。
原則
- クライアントは要求を開始し、応答を待ち、受けとり時に応答を処理する。
- クライアントは通常、1つ、あるいは少数のサーバーとだけ接続する。
- クライアントは、多くの場合GUIを使い、ユーザーと対話する。
- サーバーは要求を開始しない。
- サーバーは、接続されたクライアントからのネットワーク要求に応答する。
- サーバーは一般的に、ユーザーを承認し、要求された処理を行い、結果を生成する。
- サーバーは、応答としてデータをクライアントへ転送する。
利点
- 高セキュリティ 全てのデータはサーバーに保存される。一般的にサーバーはほとんどのクライアントよりもセキュリティ管理が強固である。
- データの一元化 データはサーバーにしか保存されないため、管理者にとってデータへのアクセスやデータの更新が容易。
- 運用が容易 システムの役割と責務を、ネットワークで接続された複数のコンピューターに分割できる。クライアントはサーバーの保守や更新や配置変更などに影響を受けない。
例
- インターネット／イントラネットでのWebブラウザベースプログラム
- バックエンドのサービスにアクセスするWindowsフォームアプリケーション
- メールソフトやFTPクライアント、あるいはDB管理ツールのような、リモートのデータにアクセスするアプリケーション
- 運用管理ツールやネットワークモニタのような、リモートシステムを操作するツール
発展系：
- クライアント／キュー／クライアント サーバーがデータを保持するキューとして振舞う。クライアントはファイルや情報を配布したり同期させたりできる。
- P2Pアプリケーション クライアント／キュー／クライアントがさらに発展したもの。P2Pでは多数のクライアント間で情報共有するため、クライアントとサーバーの役割が逆転している。
- アプリケーションサーバー シン・クライアントからの操作によって、サーバーがアプリケーションを実行するスタイル。
コンポーネント指向
コンポーネント指向のアーキテクチャは、システムの設計・構築に対するソフトウェア工学的なアプローチである。 明確に定義されたインタフェースを公開する、機能的または論理的なコンポーネントに分割するという設計をとる。 抽象度はオブジェクト指向より高く、オブジェクトに特有の問題（例えば通信プロトコルや状態の共有）は取り扱わない。
原則
- 再利用可能 コンポーネントは通常、別のシナリオやアプリケーションで再利用できるよう設計される。汎用性は必須ではなく、場合によっては一つのタスクに特化したコンポーネントを作成してもよい。しかし、そのタスクが別の状況でも必要になった時には、そのコンポーネントを再利用できるべきである。
- コンテキスト非依存 状態データのような、一つのシナリオに特化した情報は、コンポーネントが内部に保持するのではなく、外部から渡されるべきである。そうすれば別の環境およびコンテキストでも動作できる。
- 組み合わせ可能 他のコンポーネントと組み合わせて、アプリケーションの大きな部分を構成することが可能であるべきである。
- カプセル化 機能を利用するためのインターフェースを公開し、プロセスの内部的な詳細や内部変数や状態などは公開しないようにするべきである。
- 独立 他のコンポーネントへの依存関係がまったくないか限りなく少ない状態で、適切な環境に配置できるべきである。また、他のコンポーネントやシステムに影響を与えることなく、独立してバージョンを上げることができるべきである。
利点
- 配置が簡易 互換性のある新バージョンが出たときに、他のコンポーネントやシステム全体に影響を与えずに置き換えることができる。
- コスト削減 サードパーティ製のコンポーネントを使うことで、開発・保守のコストを分散できる。
- 自由度 実行環境で利用可能なものであれば、どんなプログラミング言語でコンポーネントを書いてもよい。開発者は慣れた言語や技術を使うことができる。
- 開発が容易 定義された機能を提供する、公開されたインターフェースを実装する。その際、システムの他の部分に与える影響を気にしなくてもよい。
- 再利用可能 開発および保守のコードを複数のアプリケーションやシステムに行き渡らせることができる。
例
コンポーネントの中には、メソッドやイベントやプロパティを通して直接やりとりするのではなく、メッセージベースのインターフェースを使うものもある。 アプリケーション内部で使われるコンポーネントには以下のようなものがある。
- UIコンポーネント。グリッドやボタンなど。「コントロール」とも呼ばれる。
- ビジネスロジックコンポーネント。処理にビジネスルールを適用する。
- データアクセスコンポーネント。RDBのようなデータストアとやりとりする。
- ヘルパーコンポーネント。他のコンポーネントで使われる機能の一部を公開する。
論理的多階層
論理的多階層モデルでは関心事をうまく分離できる。 論理的多階層型アーキテクチャは、役割(他の層とのやりとりの種類)と責任(機能)を各層に分配する。 たとえば、Webアプリケーションの典型的な設計では、プレゼンテーション層（UIに関連した機能）、ビジネス層（ビジネスルールの処理）とデータアクセス層（データアクセスに関連した機能）から成り立つ。
機能を論理的階層に分けることで、セキュリティ運用上の境界が明確になり、コンポーネントを再利用できる機会が増え、テストと運用が単純化され、アプリケーション内部の通信要件が定義される。
原則
- コンテキストの明確な定義 分析によりシステムに必要な主要コンポーネントを規定し、コンポーネント間の関係や相互作用を決定する。
- 抽象化 この設計は、モデル全体を見通せる程度に抽象化されているが、論理層同士の関係が理解できる程度には詳細であるべきである。
- カプセル化 この設計ではデータ型やメソッドやプロパティといった実装に前提を置くべきではない。
- 機能階層の明確な定義 この設計では各層の機能を明確に分離するべきである。たとえばビジネス層やデータアクセス層のような下位層はサービスを公開しインターフェースを実装する。サービス層やプレゼンテーション層のような上位層はUIまたはAPIを実装し状態を保持する。上位層は下位層に命令を送り、データは層を越えて上向きにも下向きにも渡される。
- 高凝集 各層には、その層に直接関係がある機能だけが含まれているべきである。
- 粗結合 下位層が上位層に依存していなければ、他のシナリオでも再利用できる。層同士の通信は粗結合を実現する抽象化を基盤におく。抽象化はインターフェースや共通基底クラスやメッセージベースのやりとりや一般的なOOのパターンなどで実装される。
利点
- 層同士の結合度が低く、各層のインターフェースの実装を入れ替えることができるため、ソリューションの運用保守が容易。
- 論理層のインターフェースが再利用を念頭において設計されている場合は特に、いろいろな層が公開する機能を他のソリューションからも再利用できる。
- 論理層の境界で作業を分担できる場合は、分散型開発が容易。
- 論理層を物理的多階層に分散させることで、スケーラビリティ、耐障害性、パフォーマンスを改善できる。
- うまく定義された論理層インターフェースをもち、実装を入れ替えられることでテストが容易になる。
- ハードウェアと配置の問題や、外部依存性などを考慮しなくてもよくなる。
- 抽象化の度合いを変更できる。論理層は階層的なため、層が変われば抽象度も変わる。
例
- 会計や顧客管理などの業務アプリケーション。
- データを扱い表示するアプリケーション。
- 企業Webアプリケーションまたは企業Webサイト。
- ビジネスロジックをAPサーバーに集約した、企業用デスクトップアプリまたはスマートクライアント。
- APサーバーに接続する企業用モバイルアプリケーション。
メッセージバス
メッセージバスアーキテクチャは既知のフォーマット群に従うメッセージを送受信できるソフトウェアシステムを使うという原則を記述する。 メッセージバスソフトウェアを使うシステムは実際の受取人を知ることなく通信できる。 メッセージバスシステムは、メッセージの内容または他の手段で提供される指示に基づき、（一般的にはPublish/Subscribeデザインパターンの実装を用いて）適切な受取人に、あるいは二人以上の受取人にメッセージを送る。 メッセージはWebサービスで公開されることもあるが、これは必要条件ではない。 メッセージバスシステムは、電子メールメッセージのようなテキスト形式か、メッセージ・キューイング・システムにおけるメッセージとしてメッセージを送受信するかもしれない。
原則
- メッセージ指向の通信 アプリケーション同士の通信は共通のスキーマを使ったメッセージに基づく。
- 複雑な工程ロジック 巨大で複雑なアプリケーションの代わりに、個々のタスクを実行する小さなアプリケーション群を作り、それらをつなぎ合わせて複雑な動作を実現する。
- 工程ロジックの修正 メッセージバスとのやりとりが共通のスキーマと命令に沿っているため、アプリケーションを追加したり削除したりすることで、メッセージを処理するロジックを変更できる。
- 異なる環境の統合 共通の標準に従うメッセージ指向の通信により、Microsoft .NET や Javaのように異なる環境で開発されたアプリケーションを使うことができる。
利点
- 拡張性 既存アプリケーションに影響を与えずにアプリケーションを追加削除できる。
- 柔軟性 バスのインターフェースを更新しても、既存メッセージとの互換性が保たれていれば既存アプリケーションに影響を与えない。
- 複雑度の低減 個々のアプリケーションはバスとの通信だけに依存すればいいので、複雑さを低減できる。
- 高パフォーマンス アプリケーションの通信に仲介するものがないためパフォーマンスが向上する。メッセージバスがメッセージを送る速さだけに依存する。
- スケーラビリティ 同時に複数の要求を処理するために、バスにアプリケーションのインスタンスを複数接続できる。
- 各アプリケーションは、複数アプリケーションへ接続するのではなく、メッセージバスだけに接続すればよい。
例
- エンタープライズサービスバス (ESB)
- インターネットサービスバス (ISB) 企業ネットワークではなくクラウドのアプリケーションをつなぐ。URIとポリシーに基づきルーティングする。
MVC (モデル・ビュー・コントローラ)
モデル・ビュー・コントローラは、要求やユーザー操作を扱い、UIやアプリケーションデータを操作するときに用いられるスタイルを表す。 MVCパターンはUIの処理をモデル、ビュー、コントローラの3つの異なる役割に分割する。
原則
- 関心の分離 MVCスタイルの大原則は、UI処理に関係する関心事をモデル、ビュー、コントローラにはっきり分離することである。モデルはデータを表現し、ビューはUIを表現し、コントローラは要求を受け取って処理を実行する。
- テスト範囲を広げるためにPassive Modelパターン(モデルが更新通知しない)を使う Passive Modelパターンを使ってビューとモデルの依存性を断ち切ることで、実装オブジェクトをモックオブジェクトに入れ替えることができる。モックオブジェクトによって、テストの時に実装オブジェクトのふるまいを模倣させることができる。
- ビューにデータの変更を伝えるためにイベントを使う モデルが管理するデータを変更したときにビューに通知するためには、一般的にObserverパターンが使われる。
- ビューから処理ロジックを排除する 処理ロジックはビューではなくコントローラが扱うべきである。ただし、UIコントロールのイベントを処理するなど、処理ロジックをビューに置く要求があるような場合もある。可能であれば実際のロジックはコントローラが実装し、ビューのイベントハンドラはイベントをコントローラに渡すようにすべきである。
- 大量のデータを扱うときはActive Modelパターン(Observerパターン)を使う 大量で大きいデータを処理するビューを設計するときは、ビューからモデルにアクセスすることを検討せよ。このデザインパターンはActive Modelと呼ばれるMVCの変形である。
- ビジネスロジックとUI処理ロジックを混在させない MVCのコントローラはUI処理に関連したルールを実装するだけにすべきだ。コントローラでビジネスルールを実装してはいけない。
Passive ModelとActive Modelについては『Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC)』 [Burbeck92] を参照
利点
- テスト可能性 モデルとコントローラは単なるクラスであるため、他のクラスと同様に単体テストできる。
- 再利用性 プレゼンターは互換性のあるビューで再利用できるし、逆も可能である。
- 運用性 関心事の分離により、依存関係を明確にし、コードをより保守しやすい形に構造化することが容易になる。
例
- ASP.NET MVC
物理的多階層
このアーキテクチャスタイルは論理的多階層と同じように機能を複数の部分に分割することについて述べているが、部分というのが物理的に別のコンピュータに置かれる物理層になる。 これはコンポーネント指向とともに進化し、通信にはメッセージベースの方式ではなくプラットフォーム依存の手段が用いられる。 物理的多階層は論理的多階層と比べてハードウェアやOSに対する要求が多く、現代的なアプリケーションにおいては一般的に論理的多階層の手法ほど有効ではないと見られている。
原則
- 物理的多階層アーキテクチャの特徴はアプリケーションやサービスの機能を分解して分散配置することにあり、スケーラビリティ、可用性、運用性、リソースの利用効率を上げる。
- 各物理層は、直接隣り合う物理層を除いた他の物理層から完全に独立している。n層はn+1層からの要求の受け取り方と、n-1層への要求の送り方と、結果の扱い方だけを知っていればよい。
- 物理多階層には最低でも3つの論理層がある。各論理層の機能は、物理的に異なるサーバーに置かれ、そのサーバーに関して責任を持つ。
- 1つの論理層に対する機能の追加変更であればアプリケーション全体の再配布は不要。
- もし1つ以上のサービスやアプリケーションが特定の論理層が公開する機能に依存している場合は、その論理層は1つの物理層に配置される。
- 物理的多階層アーキテクチャの典型例はプレゼンテーション物理層、ビジネス物理層、データ物理層の3階層である。
- 一般的には、プレゼンテーション物理層はプレゼンテーション論理層(UI processing and rendering)を管理し、ビジネス物理層はビジネス論理層(business rules processing)やサービスインターフェースを管理し、データ物理層はデータ論理層(data access logic)やデータストアを管理する。
利点
- 運用性 物理層は他の物理層から独立しているので、アプリケーション全体に影響を与えずに更新や変更を実施できる。
- スケーラビリティ 物理階層は論理階層に基づくので、アプリケーションのスケールアウトがかなり容易である。
- 柔軟性 物理層は独立して運用・増強できるので、柔軟性が向上する。
- 可用性 システムを容易に増強可能なコンポーネントに分割できるモジュール型アーキテクチャを活用して、可用性を向上できる。
オブジェクト指向
オブジェクト指向アーキテクチャはアプリケーションやサービスのタスクを独立性が高く再利用可能で自己完結したオブジェクトに分割するプログラミングスタイルである。 個々のオブジェクトはそのオブジェクトに関連があるデータとふるまいを保持する。オブジェクト指向設計では、ルーチンや逐次命令の集合ではなく、協調するオブジェクトが連携したものとしてシステムを捉える。 オブジェクトは分離しており、独立で、疎結合している。オブジェクトはインターフェースを介して連携し、メッセージを送受信する。
原則
- 抽象化 処理の基本的な特徴を保持する汎化により、複雑な処理を減らすことができる。汎化された処理は、処理を呼び出すコードと処理を実装するコードとのインターフェースを提供する。たとえば、GetやUpdateのような単純なメソッドを使ったデータアクセス処理をサポートする既知の定義として、抽象インターフェースを使うことができる。抽象化の別の形として、構造化データを持つ2つのフォーマットをマップする際のメタデータを挙げることができる。
- 複合化 オブジェクトは別のオブジェクトに集積されることがあり、内部オブジェクトとして他クラスから隠すか、公開するかを選択できる。複合オブジェクトは共通的なタスクを簡素化したインターフェースを公開できる。
- 継承 オブジェクトは他のオブジェクトを継承でき、基底オブジェクトの機能を呼び出せる。あるいは、単純なオブジェクトを継承し、特定の機能を新しいふるまいで上書き(オーバーライド)してオブジェクトの動作を変更しながらも、他の機能についてはコードを複製したりせずに利用することができる。保守や更新が容易になり、基底オブジェクトの変更は派生オブジェクトすべてに反映される。
- カプセル化 オブジェクトの機能はメソッドやプロパティやイベントによって公開される。しかし、実装や内部状態や内部変数は他のオブジェクトやコードには見せない。更新や置き換えが容易になる一方でインターフェースの互換性が保たれ、他のオブジェクトやコードに影響を与えない。
- 多態 アプリケーションの処理を提供する基底型の振る舞いをオーバーライドできる。
- 分離 コードの実装を、呼び出し側コードから見たインターフェースから分離する。オブジェクトを利用する側がオブジェクトの公開された特性を全て知っている場合、オブジェクトは密結合されている。オブジェクトを利用する側が知っていて、かつオブジェクトが実装する抽象インターフェースを定義すれば、オブジェクトと利用側の結合を疎にすることができる。そうすれば、インターフェースの呼び出し側に影響を与えずに、実装を差し替えることができる。
利点
- オブジェクト指向設計によりアプリケーションがより現実世界の要求に近づく。
- データとふるまいがカプセル化されていることで以下のことが容易になる。
- 各コンポーネントの動作を理解する。
- 各コンポーネントを個別にテストする。
- インターフェースを変更せずにデータの内部表現を変更する。
- すでに存在するオブジェクトをもとに新しいオブジェクトを得ることができる。
- 開発工数を減らせる。
- テスト範囲を減らせる。 (新機能部分だけでよい)
- 多態と抽象化により、再利用性と拡張性を得られる。
例
- ビジネスにおける実在物、たとえば顧客や注文などを定義する。
- 科学や経済の複雑な演算を実現するオブジェクトモデルを定義する。
サービス指向
サービス指向アーキテクチャは、他のサービス（通常Webサービス）が提供する機能を利用するアプリケーションで用いられる。 サービス同士は、ビジネスプロセスを実行するための情報を交換し合う。 このアプローチではサービス間が疎結合になり、異なるOS、プラットフォーム、プログラミング言語を使うことができる。 SOAはオブジェクト指向とコンポーネントベース設計から発展し、疎結合や、分散された機能単位の組み合わせを活用する。
原則
- サービスは自律的。サービスは個々に運用・開発・配置・版管理される。
- サービスはモジュール化されている。個々のサービスは、特定のタスクか、または密接な関連のある(凝集した)タスク群を実行する。異なるタスク群を実行するサービスを使ってアプリケーションを組み立てることができる。
- サービスは分散可能。通信プロトコルをネットワークがサポートしているのなら、サービスはネットワーク上のどこにあってもよい。
- サービスは定義されている。個々のサービスは、例えばWSDLサービス定義のような、ユーザーがサービスを使うための情報を公開する。
- サービスは共有可能。アプリケーションや他サービスから、共通で互換性のある機能を提供するサービスを利用できる。
- サービスは疎結合。個々のサービスは他サービスに依存しておらず、インターフェースが互換性を持つ限りは、サービスを使っているアプリケーションを壊さずに置き換えたり更新したりすることができる。
- 境界は明確化されている。明確に定義されたメッセージを渡すことで、明確な境界を越えて操作が呼び出される。
- サービスはスキーマと契約を共有する。サービス同士が通信するとき、（クラスではなく）契約とスキーマを共有する。
- 互換性はポリシーに基づく。ここでのポリシーとは、例えばトランスポート、プロトコル、セキュリティといった機能の定義を意味している。
利点
- サービスの再利用。再利用するためにコンポーネントを書いたりモジュールのコードを書いたりする代わりに、サービス全体を再利用する。
- 相互運用性。組み合わせ可能なインターフェースや複数プロセスをまたがるアプリケーションを作成したり、情報交換したり、さまざまなクライアントや他サービスとやりとりしたりするために、結合・再利用が可能。
- サービス連携。アプリケーションは認証のような連携サービスを利用することができ、資源やアプリケーションを統合しながらも、自律的にサービスを維持し、自治的なポリシーの適用を保証できる。
- ドメインの調整。標準インターフェースを持つ共通サービスの再利用は、ビジネスとテクノロジーの機会を増やし、コストを下げる。
- 抽象化。サービスは自律的で、正統な契約を通してアクセスされる。それにより、疎結合と抽象化が実現される。
- 発見可能。サービスは、他のアプリケーションやサービスが場所を特定し、インターフェースを自動的に決定できるようにするための説明を公開できる。
例
- 決済処理ゲートウェイ