第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]）。

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

[iteman]

ドメイン特化言語の利点

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

しかし、プログラミングの利便性、静的な解析、形式的な検査、デバッキング、自動ドキュメント生成、最適化というAOLの利点は、開発コストやメンテナンスコストを差し引いても余りあるものだ。

[iteman]

マルチパラダイムデザインを適用した開発プロセス

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

1. 直観に従って、問題をサブドメインに分割する（4.1.4項）。
   • そのドメインでの経験から直観的に
     • 固有の歴史的意味と経験に基づくものを内包する
   • 未経験のドメインの場合、問題全体を分析する。（ステップ3および第4章を参照）
2. これは以前に経験したことがあるだろうか。
   • 既存の設計成果の再利用を検討する。
3. アプリケーションのサブドメインを分析する。
4. ソリューションドメインを分析する。
   • 自分やチームの経験、加えて第三者の経験（パターン）に基づくことができる。
   • 経験に基づくことができない場合には設計者の直観に基づくことができる。
5. アプリケーションドメイン分析の結果に基づいて、ソリューションドメイン分析を計画する（第7章）
   • マルチパラダイムデザインの肝
6. アプリケーション指向言語（Application-Oriented Language; AOL）を評価する。

[iteman]

理想的なサブドメイン分割

7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.186)

4.2節で議論したように、アプリケーションドメインを互いに分離されたサブドメインに分割することが重要である。このとき、別のアプリケーションで再利用できるようにサブドメインに分割できれば理想的だと言える。例えば、コンパイラのために書いたシンボルテーブル管理コードは、リンクエディタでも利用できるだろうし、デバッガやそのほかのソフトウェア生成ツールでの利用を考慮に入れて設計することもできるだろう。

これはサブドメイン分割の際に、そのサブドメインに水平的な性格（主たるドメイン以外のドメインでの利用が可能かどうか）を与えられるかどうかを検討する価値があることを示す。例えば、ORMドメインのサブドメインDBAL（Database Abstraction Layer）を、そのORMドメインのみで利用可能として設計するのか、その他のドメインでの利用も考慮に入れて設計するのか。

[iteman]

サブドメイン（分割）の品質向上のための目標

7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.187)

• 理想的には、この分割は本質的で互いに結合していないドメインの切れ目に沿っているのが望ましい。
  • ドメインの中には、それ1つだけで十分に高いマーケット性を持つというものもある。このことが、適したドメインであるための（必要条件ではないけれども）十分条件であることも多い。
• ドメインは互いにできるだけオーバーラップしないのがよく、また干渉し合うのもできるだけ避けるのが望ましい。
• 同一の共通性が複数のドメインの中に存在するというのも望ましくない。

[iteman]

ソリューションドメイン上のトレードオフ（フォース）がアプリケーションドメイン分析に影響を与える

7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)

このようなアーキテクチャ上のトレードオフが、各サブドメインの共通性分析に影響を与えるのだ。さらに、それを実現するためのサブドメインとモジュールの独立性にも影響を与えることになる。

以下のステートメントがあり、

typedef int Int;

それを処理する以下のような文法を考える。

type_name decl_list;

ステートメントにある型識別子intを最初のフェーズである字句解析で検証（意味解析を伴う）しようとすると字句解析ドメインから意味解析ドメインへの依存が必要になる。

name decl_list;

しかし、この文法ではnameが型識別子であることの検証は意味解析フェーズまで遅延されるため、字句解析ドメインから意味解析ドメインへの依存は不要である。しかし、検証と意味解析の結合度は増すことになる。

[iteman]

"糊づけ"ドメイン

7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)

stringのような抽象が収まるようなドメインについて。基本ビルディングブロックドメインがその候補になるだろうが、標準ライブラリやOSのAPIでサポートされる場合も多い。このようなドメインを包含するものは「ツールキット」(tool kit）と呼ばれることがある。[Gamma1995]

[iteman]

ドメイン分析と繰り返し

7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)

ドメイン分析が終わったならば、設計者は最初の分割の基準が依然適切なものであるかどうかを確認することになる。ドメイン分析の結果、抽象が広げられたり変形させられたりするが、そのことによりドメイン間の結合を変更しなくてはいけない可能性が発生する。このような結合のシフトの結果、サブドメインの境界を変更したほうがよいとわかることもある。その場合には、問題の再分割により、新しい認識に基づくサブドメインを決定すべきだろう（通常は、設計詳細のチューニングを行うことになる）。このプロセスを繰り返して収束させる。

[iteman]

ドメインの抽象の導出に設計者の直観を利用する

7.3 例：単純なランゲージトランスレータ 7.3.2 サブドメインに適用できる正しいパラダイムの見つけ方 (p.191)

ここで注意してほしいのは、ドメインの語彙から直接的に可変性テーブルを作成するのではないことである。ドメインの抽象を導き出すためには、設計者の直観を利用する。この直観をガイドするのに経験則を用いることができ、その経験則に従えば、広範な共通性を基盤とする抽象を探し出す適切な足場を得ることができるだろう。[Weiss+1999]では、設計を3つの観点から見るようにと提言する。以下はその観点の優先順位である。

1. ドメインの外部インタフェースにおける抽象
2. ドメインにおける仕事の単位（例えば、内的な状態と状態遷移）
3. そのほかのすべてのもの

[iteman]

共変とモデルの洗練

7.3 例：単純なランゲージトランスレータ 7.3.2 サブドメインに適用できる正しいパラダイムの見つけ方 (pp.194-195)

このテーブルの2つの列がほとんど同一であることに注意しよう。すなわち、typedef、識別子、関数などといったシンボルの型によって可変性を表現している2番目の列と、整形アルゴリズムにおける可変性を表現している最後の列である。それぞれの列は別個の可変性範囲を定義している。しかし、これらに対する可変パラメータは、同一の設計変更を引き起こす。すなわち、実行時構造と整形化（formatting）である。このとき、この2つの可変パラメータは共変（covariant）であると言う。
…
すなわち、可変パラメータSymbole Table FormattingとLayoutは共変である。2つのパラメータが共変であるとき、その2つの可変パラメータを包含する図の部分の、リーフ（葉）ではないノードを取り除くことができる。

共変である可変パラメータ（またはドメイン）はそれらを包含するリーフノードをエントリポイントとするドメインと見なすことで、依存関係を縮退させることができる。これはモデルの洗練のために役立つだろう。

可変性依存図 共通性ドメイン：Name

縮退した可変性依存図 共通性ドメイン：Name

p.195の図にパッケージ（ドメイン）を加えたもの。

[iteman]

設計の実装

7.3 例：単純なランゲージトランスレータ 7.3.3 設計と実装 (p.197)

この段階で、コードの中から構造を直接的に見つけ出せることも多い。

私の場合、Coplien氏の提唱する設計（7.4節を参照）は多くの場合コーディングを通して行っている。より正確に言えば、粗い設計は直観的または経験的に頭の中にあり、コーディングを通してそれが洗練・修正されるというものである。この点についてはCoplien氏の見通し以上のものがコーディングという活動に含まれていると考えることもできるだろう。

[iteman]

設計されたドメインモデル

7.4 分析ではなく、設計を 7.4.1 分析なのか、アーキテクチャなのか、それとも設計なのか？ (pp.198-199)

マルチパラダイムデザインのアクティビティは、伝統的な概念で言えば、分析、アーキテクチャ、設計のどれに最もあてはまるものなのだろうか。古典的な意味での分析ではないことだけは確かだ。なぜならば、マルチパラダイムデザインではドメインの知識の組織化を行うのであって、その知識を獲得するからではないからだ。構造と分割の基準を考え、そして（構造における）「ハウ（how）」に焦点をあててきたのであるが、それは（振る舞いにおける）「何（what）」を超越するものだ。ここでドメイン知識を組織化するために用いてきた知識は、新しいドメイン知を獲得してそれを組織化する際にも役立つ。語彙をサブセットにクラスタ化することができ、このことからドメイン構造についてのヒントが得られる。しかし、最終的に分割を決定するのが洞察や直観であることには変わりがない。最適な方法は、システムをどのように拡張するかという予見に基づいて分割が行われることだろう。すなわち、優れたアーキテクチャは変更をカプセル化する。そして、何度も繰り返すが、経験と直観が最も優れたガイドとなり得るのだ。歴史が未来を予言するのである。

マルチパラダイムデザインのアクティビティは、設計者が経験と直観をガイドとして変更がカプセル化されたドメインモデル（ドメインの構造、アーキテクチャ）を設計（デザイン）することである。そのようなドメインモデルはドメイン駆動設計でいうところの深いモデルといえるだろう。

[iteman]

Coplien氏のモデル駆動設計

第6章 ソリューションドメイン分析 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン パターンとマルチパラダイムデザイン (p.159)

マルチパラダイムデザインは、アプリケーションドメインとソリューションドメインを互いに織り合わせて、1つの構造に収束させる。この構造は、それぞれのドメインのフォースを調和させたものである。

7.4 分析ではなく、設計を 7.4.1 分析なのか、アーキテクチャなのか、それとも設計なのか？ (p.199)

アーキテクチャの最初のレベルがアプリケーションドメイン基準に従う粗い分割であるならば、アーキテクチャの第2レベルで、ソリューションドメインの構造で支援される抽象が生成される。ここでソリューションドメインの構造と言っているのは、プログラミング言語により支援されるもののことである。これは突然の転換のように見えるかもしれない。しかし、このことが必然であること、そして、この突然に見える転換のほうが、漠然とそうかもしれないと想定していたものよりもストレートな変換であるというのは、筆者の信念である。C++を使用すれば自分たちで抽象を作成することができる。抽象の上に抽象を構築することによって、多くの場合、表現力のレベルをドメイン語彙と同一の平面上に向上させることができる。その意味で、C++はドメイン語彙を表現し構造化するための最適な道具である（ただし、それは最も基底的なレベルの表現になるだろう）。

これまで、いろいろな形で表現されてきたCoplien流の（ドメイン駆動設計の）モデル駆動設計ともいえるものが、ここではよりはっきりと表現されている。これは私の感覚を支持してくれるものである。

プログラミング言語は初期設計における関心である

マルチパラダイムデザインを使用すれば言語が支援する要素に従ってアーキテクチャの形を決めることができるけれども、それらが低レベルの技法だとか、バックエンドの技法であると言っているのではない。言語の考察と関心は、設計の最も早い段階でなされる考察に影響を与える。つまり、プログラミング言語はバックエンドや実装の関心というより、初期設計における関心なのだ。しかし、だからと言って、言語には高レベルの抽象が欠けているという意味ではない。

[iteman]

ソリューションドメインの構造がアプリケーションドメインの構造に影響を与える

7.5 例：自動微分 (pp.201-202)

• ここに挙げたアプローチのいずれを選択するかによって、異なる設計をすることになるという事実は注目に値する。異なる設計ではあっても、同じ問題に対する解決策であることには違いがない。この例から、問題の構造だけからでは設計の構造は明白にならないということがわかるだろう。解決策の構造は、解決策の技法といった実現のための戦略がどのようなものであるかを理解してはじめて出現するものなのである。

• しかし、設計上のある選択が問題の構造を自由に変えてしまうとしたら、それは問題の一部であると見なすべきだろう。

• 解決策上の選択を記述することにより、要件を適切に表現できるという例は多数ある。集中処理と分散処理の選択、実装言語の選択、オペレーティングシステムやスケジュール管理の選択などを、この例として挙げることができるだろう。

• ほかの手法とは異なり、マルチパラダイムデザインではこの点を重要だと見なし、解決策上の選択を問題に加えるというスタンスを設計に持ち込むことを推奨している。

  7.5 例：自動微分 7.5.3 値ドメイン (p.204)

自動微分という解決策を選択しないとなれば、分析のトップレベルのドメインから異なったものになるだろう。サブドメインも、ニュートンメソッドと自動微分では異なるものになる。形式微分（symbolic differentiation）をサポートするような解構造というものも考えられるだろう。ソリューション技術の選択により、ドメイン分析が変わるのである。これこそが、繰り返し開発が実施されなくてはいけない根拠になる。そしてこのことは、新しいドメインに対しては特に重要である。

[iteman]

モデルのスパイラルアップ

7.5 例：自動微分 7.5.3 値ドメイン (p.207)

ここで挙げた設計はオブジェクト指向ではない。この問題の重要な抽象を捉える多重定義のように、マルチパラダイムデザインが適切なソリューションの技法を特定を助けたのである。このような「問題」の抽象の多くはソリューションの構造を規定する力を持つ。（拙訳）
すなわち自動微分にも、ニュートン法にも、手動方式にも適っていると言えるようなソリューションの構造を見つけ出すことは困難である。
This design isn't object-oriented. Multi-paradigm design helped identify appropriate solution techniques such as overloading that capture important abstractions of the problem. Many of these "problem" abstractions foresee the solution structure. That is, it would be difficult to find a single solution structure well-suited to automatic differentiation, Newton's method, and manual techniques.

ここでいう「問題」の抽象は、以下のように、マルチパラダイムデザインによって「解決策上の選択を問題に加え」られた結果であって、はじめから存在するものではない。

元の問題: 「これまで考えられてきた設計やプログラミングの便法を可能なかぎり利用して、複雑な関数の導関数を計算する。」

変更された問題: 「自動微分を使用して、複合関数の導関数を計算する」

このような手法は現実世界で頻繁に使われているものだと考える。

[iteman]

再利用・拡張しやすい設計を

7.5 例：自動微分 7.5.4 設計の拡張 (p.208)

ドメイン分析の最も重要なゴールは、再利用と拡張に対するコストを最低限に抑えることである。優れた設計であれば、最初の段階から拡張を考慮に入れている。優れた構造であれば、変更を望ましい形で取り込むことができる。そのような構造においては、可変パラメータにより変更可能な箇所が表されているのである。

「再利用と拡張に対するコストを最低限に抑える」ために、「最初の段階から拡張を考慮に入れ」た設計を行うことがドメイン分析の要諦である。

[iteman]

再利用の2つのレベル

7.5 例：自動微分 7.5.4 設計の拡張 (p.208)

1. フレームワークの再利用
   • フレームワークの既存のコードに変更を加えずに、可変パラメータの値を変えることによって利用する。
2. フレームワーク自身の変更時の再利用
   • フレームワークに新しい機能を追加する場合も、再利用できるように設計する。

[iteman]

アウトボードパラダイムによるソリューションドメインの拡張

7.6 アウトボードパラダイム (p.209)

設計者の道具箱に揃っているようなそのような道具に対して、共通性／可変性分析を実施することができる。

ソリューションドメインにデータベースやパーサジェネレータのようによく知られたパラダイムを加えることができる。

そこで汎用的な設計戦略は、ドメインをサブドメインに分割するのに、問題に適したツールや技法に従うというものでなくてはならない。C++だけでは十分でないことも多い。パーサジェネレータ、データベース、GUIフレームワーク、状態マシンといった「自明の」技法を使い、そして、それで解決できない箇所にマルチパラダイム分析を適用することになるだろう。

[iteman]

オッカムの剃刀

オッカムの剃刀（オッカムのかみそり、英: Occam's razor、Ockham's razor）とは、「ある事柄を説明するためには、必要以上に多くを仮定するべきでない」とする指針。もともとスコラ哲学にあり、14世紀の哲学者・神学者のオッカムが多用したことで有名になった。様々なバリエーションがあるが、20世紀にはその妥当性を巡って科学界で議論が生じた。「剃刀」という言葉は、説明に不要な存在を切り落とすことを比喩しており、そのためオッカムの剃刀は思考節約の原理[2]や思考節約の法則、思考経済の法則とも呼ばれる。またケチの原理と呼ばれることもある。
― オッカムの剃刀 - Wikipedia

[iteman]

パラダイムの使用についての2つの関心

7.7 マネジメント 7.7.1 オッカムの剃刀：単純性を維持する (p.210)

パラダイムを数多く使用したからといって、価値が増すわけではない。パラダイムはボキャブラリや世界観を通じて文化を規定するのに役立つ。文化の共有自身が、開発チームを成功に導くのに計り知れないほどの価値を持つ「コンポーネント」だと言ってよい。そして開発における文化というものは、少数のパラダイムとツールだけを支援するのである。一方、正しく仕事するためには、正しいツールを使うことが重要である。どのような場合にも、単一のパラダイムをステレオタイプ的に用いたがために盲目となる側面を入れ込むという結果は避けなくてはいけない。成功するプロジェクトは、この2つの関心のバランスがとれている。

[iteman]

漸進的なパラダイムの導入

7.7 マネジメント 7.7.1 オッカムの剃刀：単純性を維持する (p.210)

新しいパラダイムの導入は安定した基盤に対して漸近的に行うべきであるし、同時には単一パラダイムだけを導入すべきである。

[iteman]

パラダイムやツールを減少させる

7.7 マネジメント 7.7.1 オッカムの剃刀：単純性を維持する (p.211)

プロジェクトをサブドメインに分割した（これについては次項参照）ならば、そのあとは「オッカムの剃刀」から洞察を得ることができ、パラダイムやツールの選択に対して適当な策を講じることが可能になる。例えば、システムを5つのドメインに分けることができ、そのうちの4つのドメインに対してはJavaで実装するのが適していて（並行性が重要なのだろう）、残りの1つはC++が適している（効率が重要なのだと思われる）という場面が考えられるだろう。このとき、特別に強要されることがないのであれば、プロジェクトをよりよく稼働させるために、利用するツール総数を減少させ、C++が適しているドメインの設計をJavaで実装できるものに変換するのがよい。

[iteman]

経験と直観による最適なパラダイムの選択

7.6 アウトボードパラダイム (p.209)

経験や直観を頼って問題をドメインに分割するというのとまったく同様に、ドメインに対して最適なパラダイムを選択するのにも、経験と直観に頼らざるを得ない。

[iteman]

ドメイン分割の基礎は経験、マーケットへの精通、直観

7.7 マネジメント 7.7.2 分割統治 (p.212)

経験、マーケットへの精通、直観が、ドメイン分割をするための最上の基礎となることが多い。問題を分割する際には、それぞれのサブ問題が独立して解決策を導くことができるように心がけるべきだろう。

[iteman]

正規性を持ったドメインに対してドメイン特化言語を検討する

7.7 マネジメント 7.7.2 分割統治 (p.213)

自動コード生成からメリットを得ることができるほどに、正規性を持ったドメインというのはめったにないのである。
設計者がそのようなドメインを見つけたときは、形式的な分析とその成果から利益を享受するために、まずはAOLの構築を検討するのが賢明である。（拙訳）
Another alternative is to generate architectural interfaces from a CASE tool, such as ObjecTime [Selic+1994]. CASE tools tend to suffer from poor linearity of change. That is, a small change to the architecture may ripple through many intermediate design artifacts, thus causing rework (or, at least, recompilation) of large volumes of code. With few exceptions, CASE tools don't express multiple paradigms wellÑmost of them rally around a single paradigm. They often lead to a false sense of security, too. Few domains are regular enough to benefit from automatic code generation.
When the designer does find such domains, it's wise to at least consider building an AOL for its benefits of formal analysis and efficiency[Weiss+1999].

[iteman]

パラダイムに適した記法の使用

7.7 マネジメント 7.7.2 分割統治 (p.214)

設計においては、複数の記法を使用しなくてはいけない場面も発生する。例えばデータベースには、テーブル記法が適しているだろう。オブジェクト指向記法が適している領域にデータベースのための記法を用いて妥協するべきではないし、またデータベースのための記法が適している領域であるのにオブジェクト指向記法で間に合わせようとすべきでもない。可能なかぎり、サブドメインごとに記法を区別しよう。

[iteman]

ソリューションドメインのフリーハンドを持つこと

7.7 マネジメント 7.7.3 C++を超えて (pp.214-215)

設計のすべての様相をC++で実現しようと無理にこじつけることによって、これらのツールの特性を見損なってしまうような設計者ならば、ツールの数が減少することに満足していられるだろう。しかしその代償として、設計に豊かな表現力を持たせること、開発コストを低下させること、保守性を上げること、といった価値ある可能性を失うことになる。

[iteman]

言語とサブドメインを密接に対応づける

7.7 マネジメント 7.7.3 C++を超えて (p.215)

複数のプログラミング言語やツールセットを使用する場合には、言語とサブドメインを密接に対応づけるのが最良の策である。個々の言語やツールごとに独自の開発文化が存在する。その文化を論理的に分離しておくことが重要なのである。

[iteman]

ドメインに対する経験が最も重要

7.7 マネジメント 7.7.4 ドメイン知 (p.215)

道具（ツール）を使っても愚かなものは愚かである。現代のソフトウェア開発に典型的とも言える短所は、未成熟なドメイン知を償うものとしての期待をオブジェクトパラダイムに寄せていることである。オブジェクトがそこに摘み取られるために存在するという間違った認識、つまり、問題に存在する語彙と解決策としてのクラスを同一視するという幼稚な考えのもとに、このような欠点が築かれることになることが多い。マルチパラダイムデザインでは、このような単純さを乗り越えて、ソリューションドメインについての徹底的な調査を実施する。さらに、アプリケーションドメインに適用できるツールとして共通性／可変性分析を提供する。もっともこれらだけではドメインに対する経験の未熟さを補うことはできない。システムアーキテクトと設計者は、システム化の対象となるビジネスについて完全に理解するべきであるし、問題のスコープについて早い時期にコンセンサスを得る必要があるだろう。オブジェクト指向で経験を積んでも、開発チームにアプリケーションドメインについての知識がなければどうしようもない。マルチパラダイムデザインは（ソリューションドメインだけでなく）アプリケーションドメインに焦点をあてるので、設計者が情報の欠如に気づくことができる。しかし、開発経験の乏しさを帳消しするものでは決してない。

[iteman]

優れた設計

7.7 マネジメント 7.7.4 ドメイン知 (p.215)

優れた設計というものは、どのような場合であろうと、審美眼、洞察、経験に依存するのである。

[iteman]

システム思考と反復

7.7 マネジメント 7.7.5 システムエンジニアリングと開発プロセス (p.216)

そして、複合問題を扱うプロジェクトを成功に導くためには、（これで十分という訳ではないが）必須である2つの戦略がある。すなわち、システム思考（systems thinking）と反復（iteration）である。

• [Senge1990] - 学習する組織――システム思考で未来を創造する
• [SwieringaWierdsma1992] - Becoming a Learning Organization: Beyond the Learning Curve (Addison-Wesley Series on Organization Development)
• [Cockburn1998] - アジャイルプロジェクト管理 (アジャイルソフトウェア開発シリーズ)
• [McConnell1997] - 新訳 ソフトウェアプロジェクトサバイバルガイド

[kumamidori]

内容を読めていないのですが、Debasish Ghosh さんによるMPDへの言及記事があったので貼っておきます。

• "Abstraction in Software - Commonality and Variability (Part 2)" 2006年3月の記事
  • http://debasishg.blogspot.jp/2006/03/abstraction-in-software-commonality.html
• 下記がその続きの考察記事のもよう
  • "Abstraction in Software - Its not all OO (Part 3)" 2006年3月の記事
    • http://debasishg.blogspot.jp/2006/03/abstraction-in-software-its-not-all-oo.html

[kumamidori]

DDDとの関連

• "Domain Driven Design : Managing Variability" 2006年9月の記事
  • http://debasishg.blogspot.jp/2006/09/domain-driven-design-managing.html

[kumamidori]

• 上記記事 "Domain Driven Design : Managing Variability" を翻訳した
  http://phpmentors.jp/post/129261828893/ddd-managing-variability