第7章 マルチパラダイム

[iteman]

この章では、問題をいくつかの部分に分割して、その各々を1つのパラダイムで設計することを考えよう。このいわゆる「分割統治」（divide-and-conquer）方式は、マルチパラダイム開発のもっとも単純な形式である。
― 新装版　マルチパラダイムデザイン p.171

[iteman]

設計のための抽象

7.1 マルチパラダイムデザインの概要 (p.171)

設計のための抽象を生み出していくことにしよう。

[iteman]

フレームワークとマルチパラダイムデザイン

7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.172)

それ以上分割されることのない再利用可能モジュールとして、フレームワークを構築しているという場合を考えてみよう。マルチパラダイムデザインをそのフレームワークに適用して、その結果フレームワーク内部に結合（coupling）を招いてしまったとする。その結合が適切なものであるかどうかは、そのフレームワークを外部から見た場合のコンテキスト、例えばパラメータ化や拡張性において判断される。このときの判断の尺度は、その結合がフレームワークの表現力を拡大し拡張を容易にするかどうかになる。

[iteman]

結合度・凝集度とマルチパラダイムデザイン

7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.172)

設計の目標の1つは、部分間の結合度（coupling）を最小化し、かつ各部分内の凝集度（cohesion）を最大化することである。1つのドメインを複数のサブドメインに分割する際、共通性に深い注意を払うことによってこの2つの達成が容易になる。サブドメインはドメインのファミリ構成員をグルーピングすることによって見出だせるが、そのグルーピングは実装技術によって自然に表現できるような共通性に基づいて行うとうまくいく。

具体的な手順

1. 簡単な共通性分析から始める。
2. それらの共通性が特定のプログラミング言語で表現できるかどうかを確認する。

再帰的に繰り返されるプロセス

7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (pp.172-173)

このようなプロセスは、1度で終了というものではなく、再帰的に繰り返されることもあるだろう。

結合度・凝集度のメリット

7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.173)

結合度と凝集度は設計上のあるいはアーキテクチャ上の原則として適用されるものであるが、どちらもコードの質そのものに直接メリットを与えるというよりは、コードを保守する人たちに与えるメリットの方が大きい。結合度を疎に保つという原則は、協同作業するチーム同士や個人同士が独立した作業をするのを容易にする。結合度が高いと、たとえ小規模なチームであったとしても、各プロジェクトメンバがコードを独立に保守するのは困難になり、ひいては設計判断をローカルに行うことができなくなる。これは生産性の低下につながる。

[iteman]

ドメインが組織上の構造に従うことの重要性

7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (pp.173-174)

ソフトウェアの疎結合は手段であり、チームの疎結合がその目的である。もしソフトウェアに関することをいっさい抜きにして、政治、文化、政策、歴史といった観点からチームの構造を記述したとすると、ソフトウェアの構造はその組織に従うはずであり、断じてその逆ではない。つまり、最良の（実践的な）ドメインというものは、共通性や可変性の原則に基づくドメイン分析から得られるというよりは、直観に従って動くマーケットやビジネス的な視点から得られるべきものである。したがって、どのような単一のパラダイムも、しっかりとしたドメイン分析により導かれたマルチパラダイムデザインの配置下にあるというのが真だといいうだけでなく、マルチパラダイムデザイン自身は一般常識やビジネスの世界で普及している構造に準ずるべきだというのも真である。そして、いつでもうまくいくような単一のレシピはないのである。

単純に技術的な分析から作られるドメインが優れているというわけではないということだろう。

1つの例として、フォールトトレラントシステムをオーディットする（監査する）というドメインを考えてみよう。…たとえ以上のような論拠が歴史の中で見失われてしまったとしても、プロダクトライン開発において培われて管理されたオーディットの組織（監査チーム）の存在から逆にそうした論拠の妥当性が推論できる。ここからも、技術的な分析結果に過剰な信頼を寄せてそれに従うよりも、組織上の強い伝統に従うことの重要性に気づかせられる。経験上言える大原則として、不完全なソフトウェアの構造に関わっていくことのほうが、組織を変更することに比べれば、よほど容易だということだ。この大原則は、ときとしてドメインの構成を決断する際のガイドとして役に立つ。

7.2 マルチパラダイムデザインのアクティビティ (p.181)

経験を積んだ設計者であれば、そのドメインでの経験から、新しいシステムのアーキテクチャを形作ることができる。高レベルでのシステム構造化は、その大部分が直観に頼ったものだ。最初の切断による「部分」は、独立したビジネス領域になる。その切断部分のそれぞれが固有の歴史的意味と経験に基づくものを内包している（7.1.1項を参照）。

[iteman]

システムの複雑さとドメイン

7.1 マルチパラダイムデザインの概要 7.1.2 複雑さの度合い (pp.175-176)

プロジェクトによっては、あまりにも複雑で一般的な抽象の各技法では歯が立たないものもあるだろう。こうしたプロジェクトが複雑である原因の多くは、単一の階層では表せないことにある。複雑なシステムは、相互に絡み合った複数の階層を伴っている。もしこうしたシステムに対してトップダウン型の技法を用いて抽象を構成しようとすると、たくさんの「トップ」から分析を始めなければならないという状況に陥る。

テレコム系のシステムの例:

• 通話を処理するためのトップ（トップレベルのサブドメイン）
• 課金のためのトップ
• 保守のためのトップ
• オペレーションのためのトップ
• 機能修正追加やシステム管理のためのトップ
• フォールトトレランスのためのトップ

こうした複数のトップの下で、抽象のツリー構造は互いに悪い影響を与える形で干渉し合う。これがシステムというものを複雑にしている理由だ。複雑さは、システムに対する独立した意味のあるビューの数に比例して増大するのだ。

[iteman]

パラダイムの適用ケースとドメイン

7.1 マルチパラダイムデザインの概要 7.1.2 複雑さの度合い (pp.176-178)

• 単一ドメイン、単一パラダイム
• 結合していない複数のサブドメイン、単一パラダイム
• 結合していない複数のサブドメイン、各サブドメインごとに単一のパラダイム
• 結合していない複数のサブドメイン、各サブドメインごとにマルチパラダイム
  • 多くのプロジェクトが、このカテゴリに分類される
• 方向付き非循環図（DAG）内の複数のサブドメイン、マルチパラダイム
• 循環を伴うサブドメイン群

[iteman]

マルチパラダイムデザインのビルディングブロック

7.2 マルチパラダイムデザインのアクティビティ (p.180)

• 共通性分析
• 可変性分析
• アプリケーションドメイン分析（問題ドメイン分析）
• ソリューションドメイン分析

[iteman]

設計は分析のアクティビティである

7.2 マルチパラダイムデザインのアクティビティ (p.180)

設計とは、アプリケーション分析結果の構造に、ソリューションドメインの構造を結びつけるアクティビティである。本書では、このアクティビティを変換分析（transformational analysis）と呼ぶことにしよう。これは分析のアクティビティである。すなわち、「構造間の対応づけをする」という分析のアクティビティであり、複数のドメイン間の「変換」を分析対象として扱うのだ。

[iteman]

パターンをドメインとして考えること

7.2 マルチパラダイムデザインのアクティビティ (p.182)

パターンをソリューションドメインの一種で、早期に考慮されるべきドメインであると考えよう。つまり、自分自身でそのドメイン経験を「再発見」するよりも、過去の成功事例に基づいてそれを築きあげた方がよい。

[iteman]

経験・直観に基づく分析

7.2 マルチパラダイムデザインのアクティビティ (p.183)

与えられた問題ドメインに対しては、いくつかのソリューションドメインがそのほかのソリューションドメインよりもうまく適合する。設計チームは、たいていの場合、適切なソリューション技法を選択するのに、これまでの経験に基づくことができる。

これは私たちが実際に日常的に行っていることだと思う。

ソリューション技法すべての分析を試みて、個々のソリューション技法がアプリケーションドメイン分析の結果に適うかどうかを調べたいと考える設計者がいるかもしれない。しかし、そのような盲目的な模索は、コスト的に見て効果的とは言えない。経験に基づくことが可能ならば、そのようにしたほうがよい。

これは、「PHPがJavaのようなものならJavaを使えばいいじゃないか」といった意見に対する答えとなるだろう。

経験に基づくことができない場合には、設計者の直観に基づくのがよい。マルチパラダイムデザインは、そのような直観に対しての「監査」として機能し、設計を正規化するための技法と語彙を提供する。

これも私たちが実際に日常的に行っていることだと思う。

[iteman]

マルチパラダイムデザインが効果的に機能するソリューションドメイン

7.2 マルチパラダイムデザインのアクティビティ (p.183)

マルチパラダイムデザインはあるプログラミング言語に特化したソリューションドメインに対して最も効果的に機能する。というのは、マルチパラダイムデザインが、ある言語機能を使用するかしないかの決定をサポートするからだ。

[iteman]

マルチパラダイムデザインの肝は変換分析

7.2 マルチパラダイムデザインのアクティビティ (p.183)

5. アプリケーションドメイン分析の結果に基づいて、ソリューションドメイン分析を計画する（第7章）

この箇所がマルチパラダイムデザインの肝になる。というのは、この箇所が設計の主要な問題の1つ、すなわち、問題を解決できる実装構造の選択を扱っているからだ。

[iteman]

オブジェクトパラダイムの選択が推奨されるとき

7.2 マルチパラダイムデザインのアクティビティ (p.184)

変換分析の結果、適切なソリューションドメイン技法として、クラスと継承、すなわちオブジェクトパラダイムが支持されることが多い。ここに記述しているよりも完全な形で、オブジェクトパラダイムを利用しているツール、技法、手法は多数ある。主流とも言えるこのような技法を用いるのは賢明である。ただし、マルチパラダイムデザインや経験により、対象としているドメインにその技法が適切であるということがわかっている場合に限って、そのような技法の選択を推奨できるのだ。

[iteman]

ドメイン特化言語の作成を検討する

7.2 マルチパラダイムデザインのアクティビティ (p.184)

アプリケーションドメインに適う実装ドメイン技術を見つけるのが困難なこともある。アプリケーションドメインの共通性と可変性が、これまでに知られているソリューションドメインのいずれにもフィットしないということもある。このような問題に対しては、ソリューションドメイン構造をカスタマイズするというのが最適であるということも多い。すなわち、そのドメインのための新しい言語を作成するのである。そのような言語のことを、「アプリケーション指向言語」（application-oriented language; AOL）と呼ぶ（「アプリケーション固有言語」"application-specific language"とか、「小さい言語」"little languages"と呼ぶこともある[Bentley1988]）。

ここでいうアプリケーション指向言語は現在のドメイン特化言語である。