Tweet

連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第7回 補遺：AAG正式版について 日本ユニシス　猪股 健太郎 2010/02/16

Page1 Page2 Page3

　1年近くかけて連載してきた「アプリケーション・アーキテクチャ・ガイド2.0解説」も今回が最終回である。

　連載を開始した2009年3月の時点で、AAG（アプリケーション・アーキテクチャ・ガイド2.0）は“完成版草稿”としてCodePlexに公開されていた。その後、AAGは2009年10月にMSDNに正式公開されたのだが、内容は“完成版草稿”からさらに加筆されている。

　今回は、正式公開されたAAGの概要や本連載記事からの変更点、そして新規に追加されたクラウド・サービスの設計について紹介する。

■正式版の構成と概要

　AAG正式版は3部構成・全28章に再構成された。

はじめに

第1部　ソフトウェア・アーキテクチャと設計

第2部　設計の基礎

第3部　アプリケーション種別

付録

　まず、全体的に読みやすくなった。それは、各章が扱う範囲が明確になったためである。具体的には、10章〜15章のコンポーネント設計と、17章の横断的関心事についての内容である。“完成版草稿”では論理階層のガイドラインの中に含まれていたこれらの内容は、正式公開版では別の章として独立させてある。

　次に、表現が一部変更された。“完成版草稿”では、アーキテクチャ設計において個別の設計判断が必要な個所のことを「ホット・スポット」と呼んでいたが、正式公開版では「鍵となる問題点（Key issues）」と表現している。

　また、そのような設計判断が必要な個所として、“完成版草稿”では「アーキテクチャ・フレーム」と「品質属性」の2種類を紹介していたが、正式公開版では前者のことを単に「横断的関心事（Crosscutting concerns）」としている。ただしこれらは表現上の問題だけであり、概念や記述内容に変更があったわけではない。

　最後に、いくつかの内容が追加された。追加された内容を表にまとめる。

AAG正式公開版における章	追加された内容
3章 アーキテクチャのパターンとスタイル	・ドメイン駆動設計 ・（MVCに関する記述は削除された）
10章 コンポーネントのガイドライン	・一般的なガイドライン ・データ･アクセス層のコンポーネント設計ステップ
17章 横断的関心事	・キャッシュの設計ステップ ・例外管理の設計ステップ ・入力値とデータ検証の設計ステップ
26章 ホスティングされたサービスとクラウド・サービスの設計	・（全体が新規追加）
AAG正式公開版で追加された内容

　本稿では、これらの追加された内容から、「3章 アーキテクチャのパターンとスタイル」に追加された「ドメイン駆動設計」、「17章 横断的関心事」の設計ステップ、そして「26章 ホスティングされたサービスとクラウド・サービスの設計」を説明していく。

■ドメイン駆動設計

　ドメイン駆動設計（Domain Driven Design, DDD）は、ソフトウェアが適用されるドメイン（業務領域）を重視し、ドメインに含まれる要素と、その振る舞いや関係性を正確に反映させたモデルを構築することを重視した設計手法である。Eric Evans氏による書籍「Domain-Driven Design」が有名である。

　ドメイン駆動設計を実践し、ドメイン・モデルを構築するためには、ドメインに対する深い理解が必要である。そのため、開発チームはドメインの専門家と共同作業しながらモデリングを進めていくことになる（ドメインの専門家が顧客自身であることも多い）。目標は、出来上がったドメイン・モデルが、顧客と開発チームとの共通言語となることである。

　そして、ドメイン・モデルが共通言語として有効に働くためには、ドメイン・モデルを純粋に保ち、実装で使用するテクノロジに依存しないようにしなければならない。そのためにドメイン駆動設計では、実装を分離したりカプセル化したりするといったオブジェクト指向技術が使われる。適切なモデル構築には高いスキルが必要となり、相応のコストがかかる。しかし、適切なドメイン・モデルを基に構築されたシステムは保守性が高く、長期にわたる運用や、その間に行われる改修に耐え得るものとなるとされる。

　ドメイン駆動設計においては、アプリケーションは一般的に4つの論理階層から構成される。

ドメイン駆動設計における論理階層	論理階層の責務	対応するAAGの論理階層
プレゼンテーション層	ユーザーとの対話を実現する	プレゼンテーション層
アプリケーション層	アプリケーションの動作をコントロールする。ビジネス・ロジックは含まない、薄い層となる	ビジネス・ロジック層
ドメイン層	アプリケーションに依存しない、ドメインに関する情報を表現する。ドメイン駆動設計において最も重要な層となる
インフラストラクチャ層	ビジネス・オブジェクトの永続化や通信などといった機能を提供し、ほかの論理階層を支援する	データ・アクセス層 および、階層横断的コンポーネント
ドメイン駆動設計の一般的な論理階層

　ただし、論理階層間の依存関係は、上の層が下の層に単純に依存するというものではない。特に、ドメイン層がインフラストラクチャ層の実装に依存してはならないとされる。

　例えば、ビジネス・オブジェクトの永続化に関しては、「リポジトリ」と呼ばれるインターフェイスを利用する設計パターンが提示されている。リポジトリはオブジェクトを取得・保存するロジックを抽象化するが、リポジトリのインターフェイスはドメイン・モデルの一部として扱われ、リポジトリの実装には依存してはいけない。

ドメイン駆動設計のリポジトリ・パターン

　以上のような設計にすることで、

（1）顧客との円滑な意思疎通
（2）要求の変化に対応できる拡張性
（3）最も重要なドメイン・モデルのテスト容易性

といったメリットを得られるようになる。

参考情報：

• Domain-Driven Design（ISBN 978-0321125217、洋書）
• Domain Driven Design Quickly 日本語版
• ドメイン駆動 （ISBN 978-4798116174）

　続いて、横断的関心事について説明する。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第7回 補遺：AAG正式版について
	1．ドメイン駆動設計
	2．横断的関心事
	3．クラウド・サービス

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

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