連載:アプリケーション・アーキテクチャ・ガイド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部 ソフトウェア・アーキテクチャと設計

1章 ソフトウェア・アーキテクチャとは?
2章 ソフトウェア・アーキテクチャの鍵となる原則
3章 アーキテクチャのパターンとスタイル
4章 アーキテクチャと設計のテクニック

第2部 設計の基礎

5章 論理多階層アプリケーションのガイドライン
6章 プレゼンテーション層のガイドライン
7章 ビジネス層のガイドライン
8章 データ・アクセス層のガイドライン
9章 サービス層のガイドライン
10章 コンポーネントのガイドライン
11章 プレゼンテーション層のコンポーネント設計
12章 ビジネス層のコンポーネント設計
13章 ビジネス・エンティティの設計
14章 ビジネス・ワークフローの設計
15章 データ・アクセス層のコンポーネント設計
16章 品質属性
17章 横断的関心事
18章 通信とメッセージング
19章 物理階層とアプリケーション配置

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

20章 アプリケーション種別の選択
21章 Webアプリケーションの設計
22章 リッチ・クライアント・アプリケーションの設計
23章 RIA(リッチ・インターネット・アプリケーション)の設計
24章 モバイル・アプリケーションの設計
25章 サービス・アプリケーションの設計
26章 ホスティングされたサービスとクラウド・サービスの設計
27章 Officeビジネス・アプリケーション(OBA)の設計
28章 SharePoint業務アプリケーションの設計

付録

マイクロソフトのアプリケーション・プラットフォーム
プレゼンテーション技術一覧表
データ・アクセス技術一覧表
システム統合技術一覧表
ワークフロー技術一覧表
Enterprise Library
パターン・カタログ

 まず、全体的に読みやすくなった。それは、各章が扱う範囲が明確になったためである。具体的には、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)最も重要なドメイン・モデルのテスト容易性

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

参考情報:

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


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

インデックス・ページヘ  「アプリケーション・アーキテクチャ・ガイド2.0解説」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間