第9章 共依存ドメイン

[iteman]

この章では、ドメインエンジニアリングの概念を汎化する。そうすることによって、マルチドメイン（multiple domain）とは何かについての意味づけが可能となり、かつそのドメインのマルチパラダイムでの実装も可能になることだろう。すでに述べたように、設計はC++の実装に仕立て上げるまで続く。ここでは、前章から引き続き、TextBufferを例として取り上げる。また、有限状態マシン（finite-state machine）についても考えていく。
― 新装版　マルチパラダイムデザイン p.229

[iteman]

従来のドメイン分析とマルチパラダイムデザインの違い

9.1 共依存ドメイン 9.1.1 ドメイン分析をマルチドメイン分析に汎化する (p.230)

SCV分析のゴールは、プロダクトのファミリ群の特性と生成を表現できるような形式手法を生み出すことである。それに対して、マルチパラダイムデザインでは、サブドメインレベルにおけるファミリに焦点をあてる。

マルチパラダイムデザインは、プロダクトファミリではなく、サブドメインの中でファミリを形成するドメインとその関連、すなわちアーキテクチャの設計に焦点をあてるということだろう。

結論を言うと、完全に独立したサブドメインに分割することは不可能であり、もしそのようなサブドメインを定義したとしても、それらを協働させることはできない。
したがって、ドメイン間の依存性を特徴づけることが重要である。そのような考慮が現代のソフトウェア研究を推進してきたのである。

ここではソフトウェア研究として、以下のものが挙げられれている。

• アスペクト指向プログラミング（Aspect-Oriented Programming；AOP）([Kiczales1997])
• 生成的プログラミング（generative programming）[Czar1999]
  • アクティブライブラリ（active library）
  • マルチレベル言語（multi-level language）
  • アプリケーションジェネレータ（application generator）

マルチパラダイムデザインでは、この課題を扱うために可変パラメータを「完全なドメイン」であると見なす。従来のドメイン分析ではこのようなことは行わない。

可変パラメータが値であれオブジェクトであれ、マルチパラダイムデザインではそれをドメインと見なすということである。ドメインとドメインは可変パラメータと通じて可変性依存図によって表現されるような構造（アーキテクチャ）を形成する。

したがって、従来のドメイン分析の特徴はSCV分析であるのに対して、マルチパラダイムデザインの技法は、SCVに加えドメイン間の関係（relationship）を抱き込んだものになっていて、SCVR分析と呼ぶことができる。SCVRという用語は[Czar1999]に登場する。しかし[Czar1999]でのSCVRは、"R"がソリューションドメインのツール（ジェネレータ、コンパイラなど）であるとされている。それに対してマルチパラダイムデザインの"R"は、設計されるべき要素という位置づけになる。また、[Czar1999]のドメインパラメータは、共通性カテゴリに関する設計の形式手法の対象であり、このこともマルチパラダイムデザインとは異なっている。

マルチパラダイムデザインでは可変パラメータ（ドメイン）によるドメイン間の関係は設計されるべき要素である。

[iteman]

設計とドメインモデル

9.2 設計と構造 (p.248)

マルチパラダイムデザインは、アーキテクチャ、すなわちコンポーネントの構造とコンポーネント間の関係を生み出す。そのようなアーキテクチャが見てとれるのは、図9.1に示したような可変性依存図においてである。可変性依存図はクラス図でもオブジェクト図でもないと認識しておくことは重要である。クラス図やオブジェクト図は、設計の低レベルで考慮すべきことを図式で示したものである。例えばバインディング時期がこのような考慮項目である。つまり、バインディング時期はアーキテクチャの構造とは無関係である。

フィーチャーモデル同様、可変性依存図が表現するアーキテクチャ（ドメインモデル）はクラス図そのものではなく、より抽象度が高いものである。バインディング時期によって実装が異なるため、クラス図はドメインモデルそのものではない。しかし、その中にはドメインモデルが見てとれる。

プログラミング言語やフレームワークの能力向上により、ドメインモデルと実装の一致（ドメイン駆動設計が提唱する単一のモデル）はより現実的な目標となってきているが、それは容易なことではない。

[iteman]

可変パラメータを受け取る必要性

9.3 例：状態遷移マシン (pp.253-254)

AbstractFSMと同様に、ImplementationFSMもUserFSMに依存することに注意しよう。しかし、その依存の仔細は異なっている。AbstractFSMはUserFSMの振る舞いに依存するのだが、ImplementationFSMはUserFSMの型特性に依存するのだ。この2つの違いは、このサブドメインを表したテーブルのそれぞれの「意味」の列に書いておいた。この「意味」の列を、ドメイン分析のSCV+RにおけるRだと考えることができる。

「意味」列で可変パラメータを受け取る必要性を説明していることを指しているのだろうか。

[iteman]

インダストリアル強度

9.3 例：状態遷移マシン (p.258)

この設計は従来の方法とは異なるが、強力なものである。ここで提示した解だけでは、まだ数多くの詳細が手付かずの状態のままであるが、ここで取り上げていないそのような詳細を決定すると、このFSMの設計がインダストリアル強度（industrial strength、産業強度＝実務で十分利用できること）を持つものになるだろう。

[iteman]

設計の選択

9.3 例：状態遷移マシン (p.258)

しかし、C++を使って状態マシンの可変パラメータを表現することは、最も簡単な状態マシンを除いて不可能だろう。SDL[Turner1993]は、状態マシンのセマンティクスを自然な形で表現することを目的とした言語の例である。対象とするドメインに適した独自の状態マシン言語を開発したプロジェクトは数多くある。その際、設計者はある選択を迫られることになる。すなわち、ここで状態マシンアーキテクチャを使うのか、あるいはAOLを使って状態マシンをチューニングするのかを決定することが必要になる。7.2節ではこのような設計選択のトレードオフについて説明している。

余談だが、状態マシンに関していえば、アーキテクチャもドメイン特化言語も、状態マシンドメイン自体の語彙でアプリケーションの一部を記述するよりも、ワークフローやジョブフロー等のより高次のドメインの機構として使う方が効果的だと考える。