Atsuhiro Kubo

@kumamidori ドメインについては、第4章 p.91 により詳しい説明があります。 #4

# ドメイン分析の初出 ``` 1.1 ソフトウェア開発の課題 ドメインとパラダイムの関係 (p.2) ``` > 本書で解決していく問いかけは、ドメインモデルとドメイン分析[Neighbors1980]に基づくものだ。 `ドメイン分析`（`Domain Analysis`）はJames M. Neighborsの[Software Construction using Components](http://www.bayfronttechnologies.com/l02draco.htm#diss80)によって提唱された。

# ドメインとファミリ ``` 1.3.5 ファミリと共通性分析 (p.11) ``` > つまり、複数の関心事にまたがって存在するような共通事項は何かを知り、その中の要素ごとにどの詳細箇所が変わるのかを知って、その上で問題を理解することが必要だ[Shaw1984]。その関心の対象になる要素を集めて、**ファミリ**（family）と呼ぶ。 > > ドメインにはファミリが含まれていることが多い（しかし必然というわけではない）。ファミリはオブジェクト、関数、クラスといった「モノ」の集合である。その「モノ」は共通の特性を有しているという理由で、グルーピングすることができる。**共通性分析**は、ファミリを設計するために用いることができるアクティビティである。 ``` 1.3.5 ファミリと共通性分析 (p.12) ``` > ドメインの中には、ファミリを形成しないようなものもある。そのようなドメインは、同一の関心や焦点を持つ領域が存在しない。…このようにファミリを形成しないものであっても、1個のドメインとして扱いたいと思う。それ自身焦点をあてるに値する分野であるという意味で、そのように扱うことにしよう。 ファミリは1つ以上の特性を持ち、特性ごとにドメインを有すると考えることができる。特性が1つしかないファミリであればそのファミリはドメインである、といえる。またドメイン階層を考慮すると、あらゆるファミリはドメインであるともいえそうだ。一方、ドメインにはファミリを形成しないものがあるため、ドメインはファミリであるとは必ずしもいえないだろう。

# 優れた抽象 ``` 1.3 設計、分析、ドメイン、ファミリ：用語定義 1.3.7 正確な抽象 (p.13) ``` > 「**抽象的**」（abstract）と「**汎化**」（general）は、「曖昧な」とか「不明瞭な」という意味ではない。正確さをもって記述されたものこそが、優れた抽象であると言える。

# Phase Shift（位相差） > It helps avoid the "phase shift" that happens after data-flow diagrams in structured techniques, while avoiding the false hope that the solution structure will match the...

# 機構と方針の分離と情報隠蔽、そして共通性・可変性 ``` 1.9 共通性分析 1.9.1 ポリシーとメカニズム (p.27) ``` > エンドユーザーにメカニズムを調べさせるべきではない。エンドユーザはビジネスドメインのポリシーに対応する設計部分だけを操作できるのが望ましい。これがParnasの説いた**情報隠蔽**の精神である。そして優れたシステムでは、共通性でメカニズムが、可変性でポリシーが表現されている。 これは、優れたシステムでは、（アプリケーションドメインAが使用するドメインXによって）共通性でメカニズムが、（ドメインXによって、アプリケーションドメインAの中で）可変性でポリシーが表現されている、ということだと考えます。 ### 通常のシステム - (A) アプリケーションドメイン - ワークフロー（ポリシー＋メカニズムが含まれる） - ... ### 優れたシステム - (A) アプリケーションドメイン - ワークフロー（Xによりポリシーのみが含まれる） - ......

# 設計とは ``` 8.2 共通性分析：共通性の設計次元軸とはなにか (p.220) ``` > 設計とは、アプリケーションドメインの構造に対して、ソリューションドメインの構造を適合させるプロセスである。言い換えれば、問題における共通性と可変性に対して、それを解決できるソリューションの共通性と可変性を取り揃えなくてはいけない。

# 変換分析テーブルからコードへの変換 ``` 8.3 1組の共通性セットにおける可変性の複数次元軸 8.3.2 共通性と可変性をC++で表現する (p.227) ``` > 変換分析テーブルとコードを軽く眺めただけで、2つは同じ設計対象に対する別表現であると、C++の熟練設計者を十分に納得させられることが重要である。しかしながら、変換分析テーブルからコードへの機械的な転換方法というものは存在しない。コード化が単純な変換であることも多いのだが、優れた設計者であれば、デザインパターンやイディオムを使って変換するのが好ましい場合を判断することができるし、そのようにしてコード化することが多い。デザインパターンやイディオムは、テーブルなどを使って機械的なやり方を提示するのが難しい。テーブルからコードへの機械的な転換を実施しないという意味で、マルチパラダイムデザインには、設計者のクリエイティブな洞察を盛り込む余地が残されている。

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

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