phpmentors-jp
第4章 アプリケーションドメイン分析
この章では、ドメイン分析を紹介する。一般的な意味での分析では、「特定」の問題やアプリケーションを調べる。それに対して、ドメイン分析は、問題やアプリケーションのファミリを対象とする。ドメインに共通性と可変性を持ち込んで、ファミリ構成員の特性を記述することができる。 ― 新装版 マルチパラダイムデザイン p.89
ドメインとドメイン分析
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)
ドメインとは何だろうか。"American Heritage Dictionary"によれば、ドメインとは「活動・関心・機能の範囲、領域」のことである。ドメイン分析という言葉は、基礎的なビジネス上の抽象を研究する、ということを意味することが多い。例えば、ファイナンシャルトレーディングはドメインである。そのドメインの抽象の中には、トランザクション、株、債権、セキュリティ、先物取引、金融派生商品、外国株などが含まれる。また、電話通信も1つのドメインである。呼出しコール、電話、回線、リレー、加入者などが、そのドメインの重要な抽象になる。ファイナンシャルトレーディングや電話通信は、アプリケーションドメイン（application domain）である。各々のアプリケーションドメインは、1個のビジネス、企業、マーケットを定義し、我々はそこから完全なシステムのファミリを見つけ出すことができる。 ドメインという用語には、数学的に形式化された意味もある。その際には、関数の「ドメイン」（定義域、domain）と「レンジ」（値域、range）という使われ方をする。「ドメイン」にこのような意味があることには、3.4節で触れておいた。マルチパラダイムデザインでは、ドメインという用語にこの両方の意味を持たせている。この両者の意味を併せ持つからこそ、アプリケーションドメインの重要な抽象をソリューションドメインの形式的な言語構成要素で表現する方法をサポートできると言うこともできる。
問題ドメイン分析とは、前者の意味のドメインから後者の意味のドメインを作ることではないだろうか。例えば、「再利用可能なFSMの領域」を分析し、抽象＝サブドメイン（AbstractFSM、ImplementationFSM、…）による「再利用可能なFSMの定義域」を作る、といったことである。
4.1 分析、ドメイン分析、それらを超えて 4.1.3 アプリケーションドメイン分析とソリューションドメイン分析 (p.95)
これまで登場してきた設計手法の多くにおいては、アプリケーション分析は設計や実装を開始する前に実施する何かだった。マルチパラダイムデザインは、実装ドメインの知識を先取りするという利点がある。オブジェクトパラダイムに要求されていた利点の1つを拡張したものとして、このアプローチを考えてほしい。その理由を説明しよう。アプリケーション構築に使用するプログラミング言語が「オブジェクト」を表現できると仮定する。分析では、「抽象」の単位として、オブジェクトを探すことになる。分析から設計、実装へと進むにつれて、（なんてことだろう。）分析での抽象がその実装言語で表現できることがわかるのだ。
既存の手法では、分析での抽象がその実装言語で表現できることがわかったとしても、それでは遅すぎるということだろう。それは単に実装の問題ではなく、解決ドメインの理解が問題ドメインの構造に影響を与えるからだと思う。
設計の肝はクリエイティブ性である
4.1 分析、ドメイン分析、それらを超えて (p.89)
この章ではこの技法や記法、手続きを説明するが、覚えていてほしいのは、設計の肝はクリエイティブ性であるということだ。抽象は芸術である。少なくとも部分的にはそうである。どのような設計者も経験、知識、見通しを駆使して、大きな問題や複雑な問題の本質的なプロパティを抽象しているのである。
共通性カテゴリによるアプリケーションとソリューションのマッピング
4.1 分析、ドメイン分析、それらを超えて (pp.88-89)
マルチパラダイムデザインでは、アプリケーション分析とそのソリューションを結びつけるのに形式化された共通要素である共通性カテゴリ（commonality category）を利用する。共通性カテゴリは設計の両側面（アプリケーションとそのソリューション）を特徴づけるものである。
アプリケーション分析ではなくドメイン分析
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)
したがって、当面のアプリケーションを分析するだけでは十分とは言えない。分析の範囲を、アプリケーションドメイン全体、さらにはマーケットドメイン、企業ビジョンのドメインにまで広げる必要がある。つまりアプリケーション分析ではなくドメイン分析を行いたいのである。
マルチパラダイムデザインとドメインエンジニアリング
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)
本書では、ドメインコンセプトを中心にした設計と実装の技法を紹介する。ドメイン分析はソフトウェアファミリを同定する技法の集合である。そして、アプリケーションエンジニアリングはソフトウェアファミリを実装し管理するための技法集合である。ドメイン分析とアプリケーションエンジニアリングを併せて、ドメインエンジニアリング（domain engineering）と呼ばれる「規範」が形成される。マルチパラダイムデザインは、ドメインエンジニアリングの一形態であり、アプリケーションドメインとソリューションドメインの両者にドメイン分析を適用する。
アプリケーションドメイン分析の重要点
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.92)
アプリケーションドメイン分析はさまざまな粒度でソリューションの構造に影響を及ぼすことになるので、問題ドメインの分析とソリューションドメインの分析を連携させて実施することが重要である。同じ理由で、1つのドメインについて、すべてのファミリ構成員を考えることも重要になる。
ドメイン分析は分析の統合レイヤーではない
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (pp.92-93)
ドメイン分析は、そのドメインの抽象に存在する共通性と可変性を統合する視点を提供する。従来の分析で見つけることのできた抽象よりも少し高レベルでドメイン分析をおこなうことはできるけれども、複数の分析を結びつけるレイヤーがドメイン分析であると見なすべきではない。ドメイン分析は、一時に1つのファミリに関わるすべてのシステムを考察対象にするのである。
抽象化のレベルと適用範囲
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)
ドメイン分析に由来する抽象は、そのドメインのすべての抽象に適用できる。それに対して、従来の分析が生み出す抽象は、その適用が保証されているのが当面のアプリケーションに限定される。
抽象化のレベルと設計情報の量
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)
優れたドメイン分析では、抽象化と具象化のバランスがとれている。抽象は詳細を隠蔽する。つまり、設計情報を忘れさせてくれる。抽象化のレベルが高ければ高いほど、設計に関係する情報は少なくなる。
適切な抽象レベル
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)
抽象のレベルは、ビジネスもしくはエンタプライズの大きさ（scope）に比例したものにすべきだろう。そのドメイン（もしくは、そのドメインの抽象の1つ）で期待されるビジネスアプリケーションを超えて抽象レベルを上げてしまうと、そのドメインにとって重要となる詳細を捨て去ってしまうことにもなるだろう。一方、その抽象によりビジネスドメインを包含することができなければ、拡張に伴って、ドメインのアーキテクチャ的な境界の外側にシステムが締め出されてしまうことになりかねない。そしてその結果、アーキテクチャの変更を余儀なくされるだろうが、それは不格好だったり高価だったりする。ドメインの設計者は、そのビジネスを熟知していなくてはいけない。
抽象化のレベルと設計情報の量
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)
ドメイン分析では、グローバルに抽象化し、ローカルに具象化する。ここで具象化すると言っているのは、実世界でその抽象のインスタンスをどのように使用するかという側面から、抽象を記述することを意味している。つまり、システムを構成するファミリのそれぞれに対して、特別なニーズを満たす汎用的な抽象を使用するのである。
この後の文で、X WindowとOpenLookで稼働させたいアプリケーションに対して、X Windowsという抽象を使用する、ローカルな具象化の例が記述されている。考えてみれば、ローカルに具象化する、というのは私が日常的に使用していることである。そのマーケット全体を満足させるような抽象ではなく、当面稼働させたいアプリケーションを満足させる抽象を使うのである。
ドメイン分析のゴールと抽象、汎用性
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)
ドメイン分析のゴールは、（問題を認識するという目的で）抽象のレベルを上げることだけでなく、汎用性のレベルを上げ、適用範囲を拡大することにある。「汎用的である」というのは「曖昧である」ことを指しているのではない。アーキテクチャ的な意味で見当違いである詳細を考えてしまうことを抑え、そのドメインにとって重要な共通性に焦点をあてることを意味している。
ドメイン分析と再利用
4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.95)
システム構造を特定のアプリケーションや顧客に合わせるのではなく、そのドメインに適したものにすることによりその構造の汎用性を保つならば、そのアーキテクチャはシステム拡張の一撃にも動じない可能性が高くなるだろう。つまり、時間と空間を超えて、設計を「再利用」できる。これが、ドメイン分析の創始者の目指していたこと（＝意図）である。
ドメイン分析の主要なアクティビティ
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)
- ビジネスドメインを特定すること
- ビジネスドメインをサブドメインに分割すること
- 各サブドメイン毎に抽象を定義すること
サブドメインとは？
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)
サブドメインとは、特別なビジネス領域もしくは技術領域のことで、汎用的なビジネスドメインやエンタプライズを描くための鍵になる。サブドメインを特定することは、マルチパラダイムデザインの肝となる部分である。
設計のスタートポイントとしてのサブドメイン
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)
これまで成功を納めてきたビジネスサブドメインは、そのビジネスの新規プロダクトを設計するための優れたスタートポイントを提供している。
優れたサブドメインとは？
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (pp.96-97)
サブドメインとして最も優れているのは、バラバラに「解体」できるようなものだ。ここで解体と言っているのは、ドメインがはっきりと識別できる可変パラメータを持ち、かつ各ドメインがその「局所化された」ビジネス上の関心事に敏感であることを示唆している。ドメインやサブドメインが適切であると、それが抽象ファミリを形成するものになる。
サブドメインの外部への依存性
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.97)
サブドメインを、アーキテクチャないしはデザインの再利用単位である、と考えるのは有用だろう。サブドメインを表現するソフトウェアは、そのほかのソフトウェアと絡み合っていない場合にかぎり、その単位で独立して再利用できる。意味のあるドメインであればどのようなものであっても、通常は可変パラメータを介して、その外部と多少なりとも結合している。仮にいかなる外部とも結合していないとすれば、別のソフトウェアと結合することが不可能になるだろう。しかし、再利用と洗練されたデザインの見地からすれば、このような依存性も最小限にするのが望ましい。
適切なドメインとは？
4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)
大部分のビジネスアプリケーションでは、経験を積んだ実務者にとって直観的にわかるドメインが望まれる。
サブドメイン分割の例
4.2 ドメイン分析を実施するサブドメイン (p.98)
このようなサブドメインのそれぞれが、ドメインそのもの、つまり「活動・形式・機能の範囲」であり、設計者が集中して考慮することのできる対象である。
ファイナンシャルトレーディング
- ファイナンシャルトレーディング
- ファイナンシャルに関する法律文書
- ヒューマン―マシンインタフェース
- プロセス間通信
- データベース
テレコム系システム
- テレコム系システム
- 呼び出し処理
- 復旧
- アドミニストレーション
- メンテナンス
- 課金
テキストエディタ
- テキストエディタ
- バッファ管理
- ヒューマン―マシンインタフェース
- テキストファイル
サブドメインとジェネレーティブプログラミング
4.2 ドメイン分析を実施するサブドメイン (p.99)
サブドメインはアプリケーションを超越する。個別の実装においては、サブシステムを生成するために、サブドメインの可変パラメータをバインドすることになる。サブドメインは、ビジネスアプリケーションに繰り返し登場する類似サブシステム群の共通性と可変性を表現する抽象である。このようなサブシステムはファミリを形成する。
幅広く適用可能なサブドメイン
4.2 ドメイン分析を実施するサブドメイン (p.100)
幸運にも、顧客という共通性が存在しないサブドメインは、ビジネスでのアプリケーションの多くに適用できるだけではなく、エンタプライズレベルで複数のビジネスにまで拡張して適用することができる。データベース、ヒューマン―マシンインタフェース、プロセス間通信、ファイル管理などは、幅広く適用可能なドメインの良い例である。このことは、範囲の広い抽象を生み出すためには、対象としている顧客ドメインを超えてそのビジネスのほかのドメインにまで関心を広げて調べることが必要であること、さらに、関連ビジネスにまでも視野に入れる必要があることを示唆している。
幅広く適用可能なサブドメインはドメインエンジニアリングの水平ドメインにあたる。あるドメインの水平性は時間とともに徐々に大きくなっていくだろう。
サブドメインのモジュール性を高める
4.2 ドメイン分析を実施するサブドメイン 4.2.2 サブドメインのモジュール性 (p.101)
サブドメインはモジュール性を持つのが理想的である。つまり、分析の結果、オーバーラップする断片が存在しないのがよいのである。システムの持つ複雑性を小さく管理可能な断片にブレークダウンして、サブドメインを決定する。このような断片を独立性を保ち高い凝集度を持つようにしておくと管理しやすい。
アスペクト指向プログラミングに代表されるようなソリューションドメインの進化により、従来は低い結合度と高い凝集度でモジュール化できなかったようなドメインをモジュール化できるようになってきている。
サブシステム・モジュールの境界とドメイン
4.2 ドメイン分析を実施するサブドメイン 4.2.2 サブドメインのモジュール性 (p.102)
これまで管理のために便宜的に使用していた構成要素（サブシステムなど）を使って、ドメインが表現できることも多い（[Booch1994]など）。しかし、ドメインは設計の論理的な単位であって、サブシステムを定義するコードに必ずしもマッピングできるとは限らない（4.3節ではその例を挙げている）。 ... すべてのサブシステムがドメインとは限らないことを知っておくことも重要である。サブシステムは、従来、コードの管理的な単位であり、設計の論理単位ではない。
ドメインの境界は必ずしもサブシステムやモジュールの境界と一致するとは限らないということである。
サブシステム・モジュールの境界とドメイン
4.2 ドメイン分析を実施するサブドメイン 4.2.3 繰り返しと階層 (p.103)
再分割を終了するのは、その抽象がマーケットの語彙よりも細分化されてしまうときである。
これは、ドメイン階層をどこまで掘り下げていけばよいのかについての指針になる。
ドメイン分析は繰り返しのプロセス
4.2 ドメイン分析を実施するサブドメイン 4.2.3 繰り返しと階層 (p.103)
ドメイン分析は、アプリケーションからサブドメインを定義してしまったならば、そのまま放置しておいていいというような先行型のアクティビティではない。ソリューションへの理解が増すにつれて、問題を考える方法も洗練されてくるものである。ドメイン分析の結果を、「完結した結論」だと仮定してしまうことには危険がある。開発プロセスは繰り返しを受け入れなくてはならない。
オブジェクトを超越する抽象の発見
4.3 サブドメインの構造 (p.104)
パラダイムの大部分は、システムの物理ビューに焦点をあて、設計者がシステムを「物理的に」分離されたモジュールへと分割すると仮定している。しかし、我々が欲しいのは、この物理ビューに加えて、論理ビューなのである。論理ビューがあれば、物理的分割を縦横する重要な抽象をはっきりと見てとることができる。厳密な分割を求めるのではなく、あるドメインの中で意味を持つ論理的な集まりを探し出すのだ。このようにすると、オブジェクトを超越するような重要な抽象を見つけ出す余地が残されることになる。
例えばアスペクト指向プログラミングを使えば、プログラミング言語が提供する構造を超えた抽象を定義することができるし、インテンショナルプログラミングのように統合開発環境上でプログラミング言語が提供する構造にオーバーレイ表示させることもできるだろう。
フレームワークは抽象である
4.3 サブドメインの構造 4.3.1 サブドメインの実装フレームワーク (p.106)
フレームワークは、ソースコードと目的コードレベルで、ソフトウェアアーキテクチャを表現するソフトウェアパッケージである。部分的に完成された実装に、個々のアプリケーションに適合させることのできる「穴」が埋め込まれている。したがって、フレームワークは1個の抽象であり、実装ファミリを特徴づける。
フレームワークとドメイン
4.3 サブドメインの構造 4.3.1 サブドメインの実装フレームワーク (p.106)
フレームワークは、通常、1個のドメイン全体に共通する実装を表現する。フレームワークとして最も一般的なのが、ユーザインターフェイスをサポートするフレームワークである。Trygve ReenskaugのModel-View-Controllerは、フレームワークファミリの基礎をなすヒューマン―マシンインタラクションの汎用的なモデルの1つである。ソフトウェア会社が社内用に開発している専用フレームワークは、そのビジネスラインにとって本質的なソフトウェアファミリをサポートする。