#commonality.analysis

[iteman]

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

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

[iteman]

既知のモデルがうまく適用できない。新しい状況に直面したときには、再現性を探しだして抽象を形成する。アナロジも経験も存在しないケースでは、演繹的な論法を使って、モデルと抽象を作成することになる。見知らぬ文化の住居を初めて目にしたならば、その住居のいずれもがどこか似ているような印象を持つのではないだろうか。つまり、「その文化のための住居」という認識の抽象が定義される。これとまったく同じことが、ソフトウェアに対しても行われるのである。 マルチパラダイムデザインは、ドメインエンジニアリングの経験を利用して、一般に認知されているドメインへと問題を分割する。設計が進行するにつれてドメインに描き込むものが増えていくが、それは貯蔵されていたものが分配されるというのとは異なる。新規に開拓するドメインに対する設計では、最初に行われる直観で行うとも言えるフェーズを省略する。必要となる原型だけを借りて、ドメイン自身を観察して分割のための鍵を探す。前もって予想を立てておいた分割基準を用いて問題から抽象を捻りだすのではなく、ドメイン自身から抽象を導き出す。あるアプリケーションにとってたまたま既存のあるパラダイムが最も優れた選択であるということになった場合に、共通性／可変性分析はその選択の正しさを補強してくれるだろう。

新装版　マルチパラダイムデザイン pp.38-39 第2章 共通性分析 2.1 共通性：抽象のエッセンス 2.1.1 演繹的共通性と帰納的共通性

未知の構造の認知について

[iteman]

ここから、設計手法というものは、共通性分析の領域に数多くのパターンを織り込んでいるものだと考えることができるだろう。つまり設計の性質を考えれば、個々のパターンを「覚えなくてはいけないもの」とか「適用しなくてはいけないもの」といった例外として考える理由はどこにもないのである。

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

[iteman]

オブジェクトパラダイムでは、意味的に関連性を持つアクティビティをグルーピングしてメンバ関数と呼び、それを使ってクラスと呼ばれる抽象を作成する。このクラスという抽象は、データ構造を持つのが一般的である。しかし、そのデータ自身やデータがシステムをどのように流れるかにはあまり関心を寄せないで、そのデータに関連する操作がどのように結びつけられるかに多くの注力を払う。関連する操作こそがこの抽象を形成しているのだが、この抽象を抽象データ型（abstract data type）と呼ぶ。

新装版　マルチパラダイムデザイン p.52 第2章 共通性分析 2.3.1 データ構造

[iteman]

振る舞いを、意味やセマンティクスとは区別しておくことが重要である。その違いは微妙で、残念なことに形式的な区別はない。しかし、その2つを区別しておくと分析がうまくいく。振る舞いは、実装と密接に結びついている。オブジェクトがどのように振る舞うかについては、気にかけることはあまりない。例えば、型の振る舞いを実現するメンバ関数の中で、命令（instruction）がどのように配列されているかに関心を寄せることはまずない。AsciiGraphicsWindowクラスもXWindowクラスもrefreshを行う責務があるが、この両者の振る舞いは異なるものになるだろう。しかし、クライアントから見ると、いずれの場合もrefreshの意味は同じである。意味はクライアントが注意を払うものだ。プログラムは、クラスが異なる振る舞いをするにしても同じ意味を持つならば、互換的に使用できなくてはいけない（この話題については、5.1節でパラダイムとオブジェクトの関係を議論する際にさらに詳しく見ていくことにする）。

新装版　マルチパラダイムデザイン p.60 第2章 共通性分析 2.3.2 名前と振る舞い

[iteman]

4. Domain-Driven Design: Problem Domain Analysis Commonality and Variation Domain Starter Sets

Agile Finland | Architecture for Scrum Teams Training 17-18 March (James Coplien) - Agile Finland

[iteman]

設計とは、アプリケーションドメインの構造に対して、ソリューションドメインの構造を適合させるプロセスである。言い換えれば、問題における共通性と可変性に対して、それを解決できるソリューションの共通性と可変性を取り揃えなくてはいけない。

新装版　マルチパラダイムデザイン p.220 第8章 1つのドメインに混在するマルチパラダイム 8.2 共通性分析：共通性の設計次元軸とは何か

[iteman]

共通性分析は、ドメイン辞書を作成することから始まる。ドメイン辞書には、そのアプリケーションの領域の語彙を文書化する。このようにする意図は、これから解決しようとする問題に絡むすべての側面を把握することだ。またそれと同時に、ソリューションのすべての側面も、可能な限り把握するためである。問題を広く深く理解する前に、顧客の言葉や要求を記述する文書の中から問題を一瞥するのである。また、自分自身の経験もここで役立つことだろう。このようなものを、「ドメイン語彙」あるいは「ドメイン辞書」と呼んでいる。これは、古くからあるソフトウェア設計ツールの1つであるが、現代の設計手法の中で再認識され始めている（この話題については[GoldbergRubin1995]を参照）。

新装版　マルチパラダイムデザイン p.43 第2章 共通性分析 2.2 分析を始めるにあたって：ドメインの語彙を定義する 2.2.1 ドメイン辞書