第4章 アプリケーションドメイン分析

[iteman]

この章では、ドメイン分析を紹介する。一般的な意味での分析では、「特定」の問題やアプリケーションを調べる。それに対して、ドメイン分析は、問題やアプリケーションのファミリを対象とする。ドメインに共通性と可変性を持ち込んで、ファミリ構成員の特性を記述することができる。
― 新装版　マルチパラダイムデザイン p.89

[iteman]

ドメインとドメイン分析

4.1 分析、ドメイン分析、それらを超えて  4.1.2 システムファミリ：ドメイン分析 (p.91)

ドメインとは何だろうか。"American Heritage Dictionary"によれば、ドメインとは「活動・関心・機能の範囲、領域」のことである。ドメイン分析という言葉は、基礎的なビジネス上の抽象を研究する、ということを意味することが多い。例えば、ファイナンシャルトレーディングはドメインである。そのドメインの抽象の中には、トランザクション、株、債権、セキュリティ、先物取引、金融派生商品、外国株などが含まれる。また、電話通信も1つのドメインである。呼出しコール、電話、回線、リレー、加入者などが、そのドメインの重要な抽象になる。ファイナンシャルトレーディングや電話通信は、アプリケーションドメイン（application domain）である。各々のアプリケーションドメインは、1個のビジネス、企業、マーケットを定義し、我々はそこから完全なシステムのファミリを見つけ出すことができる。
ドメインという用語には、数学的に形式化された意味もある。その際には、関数の「ドメイン」（定義域、domain）と「レンジ」（値域、range）という使われ方をする。「ドメイン」にこのような意味があることには、3.4節で触れておいた。マルチパラダイムデザインでは、ドメインという用語にこの両方の意味を持たせている。この両者の意味を併せ持つからこそ、アプリケーションドメインの重要な抽象をソリューションドメインの形式的な言語構成要素で表現する方法をサポートできると言うこともできる。

問題ドメイン分析とは、前者の意味のドメインから後者の意味のドメインを作ることではないだろうか。例えば、「再利用可能なFSMの領域」を分析し、抽象＝サブドメイン（AbstractFSM、ImplementationFSM、…）による「再利用可能なFSMの定義域」を作る、といったことである。

[iteman]

4.1 分析、ドメイン分析、それらを超えて 4.1.3 アプリケーションドメイン分析とソリューションドメイン分析 (p.95)

これまで登場してきた設計手法の多くにおいては、アプリケーション分析は設計や実装を開始する前に実施する何かだった。マルチパラダイムデザインは、実装ドメインの知識を先取りするという利点がある。オブジェクトパラダイムに要求されていた利点の1つを拡張したものとして、このアプローチを考えてほしい。その理由を説明しよう。アプリケーション構築に使用するプログラミング言語が「オブジェクト」を表現できると仮定する。分析では、「抽象」の単位として、オブジェクトを探すことになる。分析から設計、実装へと進むにつれて、（なんてことだろう。）分析での抽象がその実装言語で表現できることがわかるのだ。

既存の手法では、分析での抽象がその実装言語で表現できることがわかったとしても、それでは遅すぎるということだろう。それは単に実装の問題ではなく、解決ドメインの理解が問題ドメインの構造に影響を与えるからだと思う。

[iteman]

設計の肝はクリエイティブ性である

4.1 分析、ドメイン分析、それらを超えて (p.89)

この章ではこの技法や記法、手続きを説明するが、覚えていてほしいのは、設計の肝はクリエイティブ性であるということだ。抽象は芸術である。少なくとも部分的にはそうである。どのような設計者も経験、知識、見通しを駆使して、大きな問題や複雑な問題の本質的なプロパティを抽象しているのである。

[iteman]

共通性カテゴリによるアプリケーションとソリューションのマッピング

4.1 分析、ドメイン分析、それらを超えて (pp.88-89)

マルチパラダイムデザインでは、アプリケーション分析とそのソリューションを結びつけるのに形式化された共通要素である共通性カテゴリ（commonality category）を利用する。共通性カテゴリは設計の両側面（アプリケーションとそのソリューション）を特徴づけるものである。

[iteman]

アプリケーション分析ではなくドメイン分析

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)

したがって、当面のアプリケーションを分析するだけでは十分とは言えない。分析の範囲を、アプリケーションドメイン全体、さらにはマーケットドメイン、企業ビジョンのドメインにまで広げる必要がある。つまりアプリケーション分析ではなくドメイン分析を行いたいのである。

[iteman]

マルチパラダイムデザインとドメインエンジニアリング

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)

本書では、ドメインコンセプトを中心にした設計と実装の技法を紹介する。ドメイン分析はソフトウェアファミリを同定する技法の集合である。そして、アプリケーションエンジニアリングはソフトウェアファミリを実装し管理するための技法集合である。ドメイン分析とアプリケーションエンジニアリングを併せて、ドメインエンジニアリング（domain engineering）と呼ばれる「規範」が形成される。マルチパラダイムデザインは、ドメインエンジニアリングの一形態であり、アプリケーションドメインとソリューションドメインの両者にドメイン分析を適用する。

[iteman]

アプリケーションドメイン分析の重要点

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.92)

アプリケーションドメイン分析はさまざまな粒度でソリューションの構造に影響を及ぼすことになるので、問題ドメインの分析とソリューションドメインの分析を連携させて実施することが重要である。同じ理由で、1つのドメインについて、すべてのファミリ構成員を考えることも重要になる。

[iteman]

ドメイン分析は分析の統合レイヤーではない

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (pp.92-93)

ドメイン分析は、そのドメインの抽象に存在する共通性と可変性を統合する視点を提供する。従来の分析で見つけることのできた抽象よりも少し高レベルでドメイン分析をおこなうことはできるけれども、複数の分析を結びつけるレイヤーがドメイン分析であると見なすべきではない。ドメイン分析は、一時に1つのファミリに関わるすべてのシステムを考察対象にするのである。

[iteman]

抽象化のレベルと適用範囲

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

ドメイン分析に由来する抽象は、そのドメインのすべての抽象に適用できる。それに対して、従来の分析が生み出す抽象は、その適用が保証されているのが当面のアプリケーションに限定される。

[iteman]

抽象化のレベルと設計情報の量

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

優れたドメイン分析では、抽象化と具象化のバランスがとれている。抽象は詳細を隠蔽する。つまり、設計情報を忘れさせてくれる。抽象化のレベルが高ければ高いほど、設計に関係する情報は少なくなる。

[iteman]

適切な抽象レベル

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

抽象のレベルは、ビジネスもしくはエンタプライズの大きさ（scope）に比例したものにすべきだろう。そのドメイン（もしくは、そのドメインの抽象の1つ）で期待されるビジネスアプリケーションを超えて抽象レベルを上げてしまうと、そのドメインにとって重要となる詳細を捨て去ってしまうことにもなるだろう。一方、その抽象によりビジネスドメインを包含することができなければ、拡張に伴って、ドメインのアーキテクチャ的な境界の外側にシステムが締め出されてしまうことになりかねない。そしてその結果、アーキテクチャの変更を余儀なくされるだろうが、それは不格好だったり高価だったりする。ドメインの設計者は、そのビジネスを熟知していなくてはいけない。

[iteman]

抽象化のレベルと設計情報の量

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)

ドメイン分析では、グローバルに抽象化し、ローカルに具象化する。ここで具象化すると言っているのは、実世界でその抽象のインスタンスをどのように使用するかという側面から、抽象を記述することを意味している。つまり、システムを構成するファミリのそれぞれに対して、特別なニーズを満たす汎用的な抽象を使用するのである。

この後の文で、X WindowとOpenLookで稼働させたいアプリケーションに対して、X Windowsという抽象を使用する、ローカルな具象化の例が記述されている。考えてみれば、ローカルに具象化する、というのは私が日常的に使用していることである。そのマーケット全体を満足させるような抽象ではなく、当面稼働させたいアプリケーションを満足させる抽象を使うのである。

[iteman]

ドメイン分析のゴールと抽象、汎用性

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)

ドメイン分析のゴールは、（問題を認識するという目的で）抽象のレベルを上げることだけでなく、汎用性のレベルを上げ、適用範囲を拡大することにある。「汎用的である」というのは「曖昧である」ことを指しているのではない。アーキテクチャ的な意味で見当違いである詳細を考えてしまうことを抑え、そのドメインにとって重要な共通性に焦点をあてることを意味している。

[iteman]

ドメイン分析と再利用

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.95)

システム構造を特定のアプリケーションや顧客に合わせるのではなく、そのドメインに適したものにすることによりその構造の汎用性を保つならば、そのアーキテクチャはシステム拡張の一撃にも動じない可能性が高くなるだろう。つまり、時間と空間を超えて、設計を「再利用」できる。これが、ドメイン分析の創始者の目指していたこと（＝意図）である。