search

phpmentors-jp / mpdosaka

マルチパラダイムデザイン読書会
28 stars 0 forks source link

第4章 アプリケーションドメイン分析 #4

Open iteman opened 9 years ago

iteman commented 9 years ago

この章では、ドメイン分析を紹介する。一般的な意味での分析では、「特定」の問題やアプリケーションを調べる。それに対して、ドメイン分析は、問題やアプリケーションのファミリを対象とする。ドメインに共通性と可変性を持ち込んで、ファミリ構成員の特性を記述することができる。 ― 新装版　マルチパラダイムデザイン p.89

iteman commented 9 years ago

ドメインとドメイン分析

4.1 分析、ドメイン分析、それらを超えて  4.1.2 システムファミリ：ドメイン分析 (p.91)

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

問題ドメイン分析とは、前者の意味のドメインから後者の意味のドメインを作ることではないだろうか。例えば、「再利用可能なFSMの領域」を分析し、抽象＝サブドメイン（AbstractFSM、ImplementationFSM、…）による「再利用可能なFSMの定義域」を作る、といったことである。

iteman commented 9 years ago 
4.1 分析、ドメイン分析、それらを超えて 4.1.3 アプリケーションドメイン分析とソリューションドメイン分析 (p.95)

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

既存の手法では、分析での抽象がその実装言語で表現できることがわかったとしても、それでは遅すぎるということだろう。それは単に実装の問題ではなく、解決ドメインの理解が問題ドメインの構造に影響を与えるからだと思う。

iteman commented 9 years ago

設計の肝はクリエイティブ性である

4.1 分析、ドメイン分析、それらを超えて (p.89)

この章ではこの技法や記法、手続きを説明するが、覚えていてほしいのは、設計の肝はクリエイティブ性であるということだ。抽象は芸術である。少なくとも部分的にはそうである。どのような設計者も経験、知識、見通しを駆使して、大きな問題や複雑な問題の本質的なプロパティを抽象しているのである。

iteman commented 9 years ago

共通性カテゴリによるアプリケーションとソリューションのマッピング

4.1 分析、ドメイン分析、それらを超えて (pp.88-89)

マルチパラダイムデザインでは、アプリケーション分析とそのソリューションを結びつけるのに形式化された共通要素である共通性カテゴリ（commonality category）を利用する。共通性カテゴリは設計の両側面（アプリケーションとそのソリューション）を特徴づけるものである。

iteman commented 9 years ago

アプリケーション分析ではなくドメイン分析

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)

したがって、当面のアプリケーションを分析するだけでは十分とは言えない。分析の範囲を、アプリケーションドメイン全体、さらにはマーケットドメイン、企業ビジョンのドメインにまで広げる必要がある。つまりアプリケーション分析ではなくドメイン分析を行いたいのである。

iteman commented 9 years ago

マルチパラダイムデザインとドメインエンジニアリング

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.91)

本書では、ドメインコンセプトを中心にした設計と実装の技法を紹介する。ドメイン分析はソフトウェアファミリを同定する技法の集合である。そして、アプリケーションエンジニアリングはソフトウェアファミリを実装し管理するための技法集合である。ドメイン分析とアプリケーションエンジニアリングを併せて、ドメインエンジニアリング（domain engineering）と呼ばれる「規範」が形成される。マルチパラダイムデザインは、ドメインエンジニアリングの一形態であり、アプリケーションドメインとソリューションドメインの両者にドメイン分析を適用する。

iteman commented 9 years ago

アプリケーションドメイン分析の重要点

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.92)

アプリケーションドメイン分析はさまざまな粒度でソリューションの構造に影響を及ぼすことになるので、問題ドメインの分析とソリューションドメインの分析を連携させて実施することが重要である。同じ理由で、1つのドメインについて、すべてのファミリ構成員を考えることも重要になる。

iteman commented 9 years ago

ドメイン分析は分析の統合レイヤーではない

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (pp.92-93)

ドメイン分析は、そのドメインの抽象に存在する共通性と可変性を統合する視点を提供する。従来の分析で見つけることのできた抽象よりも少し高レベルでドメイン分析をおこなうことはできるけれども、複数の分析を結びつけるレイヤーがドメイン分析であると見なすべきではない。ドメイン分析は、一時に1つのファミリに関わるすべてのシステムを考察対象にするのである。

iteman commented 9 years ago

抽象化のレベルと適用範囲

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

ドメイン分析に由来する抽象は、そのドメインのすべての抽象に適用できる。それに対して、従来の分析が生み出す抽象は、その適用が保証されているのが当面のアプリケーションに限定される。

iteman commented 9 years ago

抽象化のレベルと設計情報の量

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

優れたドメイン分析では、抽象化と具象化のバランスがとれている。抽象は詳細を隠蔽する。つまり、設計情報を忘れさせてくれる。抽象化のレベルが高ければ高いほど、設計に関係する情報は少なくなる。

iteman commented 9 years ago

適切な抽象レベル

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.93)

抽象のレベルは、ビジネスもしくはエンタプライズの大きさ（scope）に比例したものにすべきだろう。そのドメイン（もしくは、そのドメインの抽象の1つ）で期待されるビジネスアプリケーションを超えて抽象レベルを上げてしまうと、そのドメインにとって重要となる詳細を捨て去ってしまうことにもなるだろう。一方、その抽象によりビジネスドメインを包含することができなければ、拡張に伴って、ドメインのアーキテクチャ的な境界の外側にシステムが締め出されてしまうことになりかねない。そしてその結果、アーキテクチャの変更を余儀なくされるだろうが、それは不格好だったり高価だったりする。ドメインの設計者は、そのビジネスを熟知していなくてはいけない。

iteman commented 9 years ago

抽象化のレベルと設計情報の量

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)

ドメイン分析では、グローバルに抽象化し、ローカルに具象化する。ここで具象化すると言っているのは、実世界でその抽象のインスタンスをどのように使用するかという側面から、抽象を記述することを意味している。つまり、システムを構成するファミリのそれぞれに対して、特別なニーズを満たす汎用的な抽象を使用するのである。

この後の文で、X WindowとOpenLookで稼働させたいアプリケーションに対して、X Windowsという抽象を使用する、ローカルな具象化の例が記述されている。考えてみれば、ローカルに具象化する、というのは私が日常的に使用していることである。そのマーケット全体を満足させるような抽象ではなく、当面稼働させたいアプリケーションを満足させる抽象を使うのである。

iteman commented 9 years ago

ドメイン分析のゴールと抽象、汎用性

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.94)

ドメイン分析のゴールは、（問題を認識するという目的で）抽象のレベルを上げることだけでなく、汎用性のレベルを上げ、適用範囲を拡大することにある。「汎用的である」というのは「曖昧である」ことを指しているのではない。アーキテクチャ的な意味で見当違いである詳細を考えてしまうことを抑え、そのドメインにとって重要な共通性に焦点をあてることを意味している。

iteman commented 9 years ago

ドメイン分析と再利用

4.1 分析、ドメイン分析、それらを超えて 4.1.2 システムファミリ：ドメイン分析 (p.95)

システム構造を特定のアプリケーションや顧客に合わせるのではなく、そのドメインに適したものにすることによりその構造の汎用性を保つならば、そのアーキテクチャはシステム拡張の一撃にも動じない可能性が高くなるだろう。つまり、時間と空間を超えて、設計を「再利用」できる。これが、ドメイン分析の創始者の目指していたこと（＝意図）である。

iteman commented 9 years ago

ドメイン分析の主要なアクティビティ

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)
  1. ビジネスドメインを特定すること
  2. ビジネスドメインをサブドメインに分割すること
  3. 各サブドメイン毎に抽象を定義すること
iteman commented 9 years ago

サブドメインとは？

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)

サブドメインとは、特別なビジネス領域もしくは技術領域のことで、汎用的なビジネスドメインやエンタプライズを描くための鍵になる。サブドメインを特定することは、マルチパラダイムデザインの肝となる部分である。

iteman commented 9 years ago

設計のスタートポイントとしてのサブドメイン

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)

これまで成功を納めてきたビジネスサブドメインは、そのビジネスの新規プロダクトを設計するための優れたスタートポイントを提供している。

iteman commented 9 years ago

優れたサブドメインとは？

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (pp.96-97)

サブドメインとして最も優れているのは、バラバラに「解体」できるようなものだ。ここで解体と言っているのは、ドメインがはっきりと識別できる可変パラメータを持ち、かつ各ドメインがその「局所化された」ビジネス上の関心事に敏感であることを示唆している。ドメインやサブドメインが適切であると、それが抽象ファミリを形成するものになる。

iteman commented 9 years ago

サブドメインの外部への依存性

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.97)

サブドメインを、アーキテクチャないしはデザインの再利用単位である、と考えるのは有用だろう。サブドメインを表現するソフトウェアは、そのほかのソフトウェアと絡み合っていない場合にかぎり、その単位で独立して再利用できる。意味のあるドメインであればどのようなものであっても、通常は可変パラメータを介して、その外部と多少なりとも結合している。仮にいかなる外部とも結合していないとすれば、別のソフトウェアと結合することが不可能になるだろう。しかし、再利用と洗練されたデザインの見地からすれば、このような依存性も最小限にするのが望ましい。

iteman commented 9 years ago

適切なドメインとは？

4.1 分析、ドメイン分析、それらを超えて 4.1.4 ドメイン分析のアクティビティ (p.96)

大部分のビジネスアプリケーションでは、経験を積んだ実務者にとって直観的にわかるドメインが望まれる。

iteman commented 9 years ago

サブドメイン分割の例

4.2 ドメイン分析を実施するサブドメイン (p.98)

このようなサブドメインのそれぞれが、ドメインそのもの、つまり「活動・形式・機能の範囲」であり、設計者が集中して考慮することのできる対象である。

ファイナンシャルトレーディング

テレコム系システム

テキストエディタ

iteman commented 9 years ago

サブドメインとジェネレーティブプログラミング

4.2 ドメイン分析を実施するサブドメイン (p.99)

サブドメインはアプリケーションを超越する。個別の実装においては、サブシステムを生成するために、サブドメインの可変パラメータをバインドすることになる。サブドメインは、ビジネスアプリケーションに繰り返し登場する類似サブシステム群の共通性と可変性を表現する抽象である。このようなサブシステムはファミリを形成する。

iteman commented 9 years ago

幅広く適用可能なサブドメイン

4.2 ドメイン分析を実施するサブドメイン (p.100)

幸運にも、顧客という共通性が存在しないサブドメインは、ビジネスでのアプリケーションの多くに適用できるだけではなく、エンタプライズレベルで複数のビジネスにまで拡張して適用することができる。データベース、ヒューマン―マシンインタフェース、プロセス間通信、ファイル管理などは、幅広く適用可能なドメインの良い例である。このことは、範囲の広い抽象を生み出すためには、対象としている顧客ドメインを超えてそのビジネスのほかのドメインにまで関心を広げて調べることが必要であること、さらに、関連ビジネスにまでも視野に入れる必要があることを示唆している。

幅広く適用可能なサブドメインはドメインエンジニアリングの水平ドメインにあたる。あるドメインの水平性は時間とともに徐々に大きくなっていくだろう。

iteman commented 9 years ago

サブドメインのモジュール性を高める

4.2 ドメイン分析を実施するサブドメイン 4.2.2 サブドメインのモジュール性 (p.101)

サブドメインはモジュール性を持つのが理想的である。つまり、分析の結果、オーバーラップする断片が存在しないのがよいのである。システムの持つ複雑性を小さく管理可能な断片にブレークダウンして、サブドメインを決定する。このような断片を独立性を保ち高い凝集度を持つようにしておくと管理しやすい。

アスペクト指向プログラミングに代表されるようなソリューションドメインの進化により、従来は低い結合度と高い凝集度でモジュール化できなかったようなドメインをモジュール化できるようになってきている。

iteman commented 9 years ago

サブシステム・モジュールの境界とドメイン

4.2 ドメイン分析を実施するサブドメイン 4.2.2 サブドメインのモジュール性 (p.102)

これまで管理のために便宜的に使用していた構成要素（サブシステムなど）を使って、ドメインが表現できることも多い（[Booch1994]など）。しかし、ドメインは設計の論理的な単位であって、サブシステムを定義するコードに必ずしもマッピングできるとは限らない（4.3節ではその例を挙げている）。 ... すべてのサブシステムがドメインとは限らないことを知っておくことも重要である。サブシステムは、従来、コードの管理的な単位であり、設計の論理単位ではない。

ドメインの境界は必ずしもサブシステムやモジュールの境界と一致するとは限らないということである。

iteman commented 9 years ago

サブシステム・モジュールの境界とドメイン

4.2 ドメイン分析を実施するサブドメイン 4.2.3 繰り返しと階層 (p.103)

再分割を終了するのは、その抽象がマーケットの語彙よりも細分化されてしまうときである。

これは、ドメイン階層をどこまで掘り下げていけばよいのかについての指針になる。

iteman commented 9 years ago

ドメイン分析は繰り返しのプロセス

4.2 ドメイン分析を実施するサブドメイン 4.2.3 繰り返しと階層 (p.103)

ドメイン分析は、アプリケーションからサブドメインを定義してしまったならば、そのまま放置しておいていいというような先行型のアクティビティではない。ソリューションへの理解が増すにつれて、問題を考える方法も洗練されてくるものである。ドメイン分析の結果を、「完結した結論」だと仮定してしまうことには危険がある。開発プロセスは繰り返しを受け入れなくてはならない。

iteman commented 9 years ago

オブジェクトを超越する抽象の発見

4.3 サブドメインの構造 (p.104)

パラダイムの大部分は、システムの物理ビューに焦点をあて、設計者がシステムを「物理的に」分離されたモジュールへと分割すると仮定している。しかし、我々が欲しいのは、この物理ビューに加えて、論理ビューなのである。論理ビューがあれば、物理的分割を縦横する重要な抽象をはっきりと見てとることができる。厳密な分割を求めるのではなく、あるドメインの中で意味を持つ論理的な集まりを探し出すのだ。このようにすると、オブジェクトを超越するような重要な抽象を見つけ出す余地が残されることになる。

例えばアスペクト指向プログラミングを使えば、プログラミング言語が提供する構造を超えた抽象を定義することができるし、インテンショナルプログラミングのように統合開発環境上でプログラミング言語が提供する構造にオーバーレイ表示させることもできるだろう。

Intentional Programming

iteman commented 9 years ago

フレームワークは抽象である

4.3 サブドメインの構造 4.3.1 サブドメインの実装フレームワーク (p.106)

フレームワークは、ソースコードと目的コードレベルで、ソフトウェアアーキテクチャを表現するソフトウェアパッケージである。部分的に完成された実装に、個々のアプリケーションに適合させることのできる「穴」が埋め込まれている。したがって、フレームワークは1個の抽象であり、実装ファミリを特徴づける。

iteman commented 9 years ago

フレームワークとドメイン

4.3 サブドメインの構造 4.3.1 サブドメインの実装フレームワーク (p.106)

フレームワークは、通常、1個のドメイン全体に共通する実装を表現する。フレームワークとして最も一般的なのが、ユーザインターフェイスをサポートするフレームワークである。Trygve ReenskaugのModel-View-Controllerは、フレームワークファミリの基礎をなすヒューマン―マシンインタラクションの汎用的なモデルの1つである。ソフトウェア会社が社内用に開発している専用フレームワークは、そのビジネスラインにとって本質的なソフトウェアファミリをサポートする。

iteman commented 9 years ago

マルチパラダイムデザインの核

4.3 サブドメインの構造 4.3.2 サブドメイン分析のアクティビティ (p.107)

サブドメインのそれぞれは、共通性と可変性という設計の「ツボ」を使って分析していかなくてはいけない。そして最終的には、この共通性と可変性がC++の実装として表現できなくてはいけない。これがマルチパラダイムデザインの核であり、マルチパラダイムデザインをほかの技法から区別するアクティビティである。

kumamidori commented 9 years ago

現状で業界的に一般的だとされている業務のあり方が必ずしも正しいとは限らない。ありのままをシステム化することに価値があるとは限らない。 （渡辺さんが時々比喩で使われる、「最新鋭の竪穴式住居」の話）。

横断的な関心事、アスペクト

（すみません。うまく書けなかったのでとりあえず写真を残しておきます。）

杉本さんによる図

20150418

杉本追記： ドメインエキスパートの共通の認識として存在するようなドメイン構造（上図左側）が必ずしも絶対ではなく、むしろ、古い時代の技術制約に縛られて出来あがったものであって、単に慣習的に続いている、ということがないでしょうか。そうであるならば、エンジニアは、ドメインの構造を所与とするのではなく、新しい技術条件のもとで新しいドメイン構造（上図右側）を提起し得るというステキな立ち位置にいるのではないか、そんなことを考えています。

kumamidori commented 9 years ago

（↑杉本さん、ありがとうございました :sheep: ）

4章冒頭

分析とは、問題（problem）を十分に考察することを言う。ドメイン分析では、関心のあるドメインの問題領域（problem area）を調べる（[CzarEise2000], 2.3節）。

  • [CzarEise2000], 2.3節　ドメイン分析 を転載

ドメイン分析の目的は以下のとおりです。 ◆フォーカスするドメインを選択し、定義します。 ◆関係するドメインの情報を収集し、首尾一貫したドメインモデルに組み込みます。 ドメインの情報源は、ドメイン内の既存システム、ドメインのエキスパート、システムの手順書、テキスト、プロトタイプ、実験、すでに知られている将来のシステムの要求内容、現在と潜在的な顧客、標準、市場調査、技術の動向などがあります。 ドメイン分析は、すでに知られているドメインの知識を記述するだけではありません。蓄積された知識をシステム的にまとめることにより、「クリエイティブ」な解決方法を可能にします。よって、ドメイン分析は、クリエイティブなプロセスであるといえます。 （中略） ドメイン分析は、以下の作業に分類されます。 ◆ドメインスコーピング（domain scoping）：対象のドメイン、投資者とそのゴール、そしてドメインの範囲を確認します。 ◆ドメインモデリング（domain modeling）：ドメインモデルを作成します。

kumamidori commented 9 years ago

https://github.com/phpmentors-jp/mpdosaka/issues/4#issuecomment-94125972 ↑この箇所が分からなかったので（サブシステムを生成？）、関連文献からメモ。

ジェネレ―ティブプログラミングは、中間成果物や最終成果物（例えばコンポーネントやアプリケーション）の生成を自動化するものです。ジェネレ―ティブプログラミングでは、プロダクトファミリのモデル化、製品を「注文」する（すなわち製品を定義する）ための手段の設計、製品を組み立てるための実装コンポーネントの準備、製品仕様を実装コンポーネントの組み立てを具体的に落とすためのマッピング、ジェネレータを用いたマッピングを実装することが必要です。ここで自動的に生成する「製品」とは、クラスや手続きからサブシステムやシステム全体にまで及びます。

システムの生成を自動化する上で鍵となるのがジェネレ―ティブドメインモデルであり、ジェネレ―ティブドメインモデルは問題空間、解決空間、そしてそれらを橋渡しする構成の知識とで出来上がっています。

大きな粒度で言えば、たとえば、 Rails でアプリケーションを作るとき、Rails が定義したWAFドメインの可変部分を私たちが作っている。 Salesforce は、個々のCRMビジネスの共通部分を作っている。

構成の知識の固定部分（サービス定義）と可変部分（設定）がパラメーターを介して結合し、実装コンポーネントの構成が行われる

kumamidori commented 9 years ago

翻訳者の１人、金澤典子さんによる文章：マルチパラダイムデザイン https://www.ogis-ri.co.jp/otc/hiroba/technical/MPD/

iteman commented 9 years ago

共通性・可変性と設計・実装

4.4 分析：俯瞰図 (p.108)

設計と実装は、アプリケーション空間の共通性と可変性を、ソリューション空間のそれらに適合させる技術である。

iteman commented 9 years ago

再度の分析

4.4 分析：俯瞰図 (p.109)

選択できる実装の技術が共通性分析と可変性分析を満たさないことがわかったならば、アプリケーション分析もしくはソリューション技術の選択、あるいはその両方を再度実施することになる。

iteman commented 9 years ago

これまでより分析に時間がかかるとしても…

4.4 分析：俯瞰図 (p.110)

すべてのものに正しい場所を与えるような「正しいソリューションを切り出すための正しいナイフ」を見つけ出すのには時間がかかる。通常の分析では、単一アプリケーションを対象にして、たった1つの実装パラダイムを片目でにらみながら、作業を進めていくだけである。しかし、分析にこれまでよりも時間がかかるにしても、プロダクトの適用性は拡大されるだろうし、時間に関するテストには合格するプロダクトになるだろう。

iteman commented 9 years ago

ドメイン分析のプロセスと抽象の設計

4.5 要約 (p.110)

ドメインの範囲を決定したあとは、サブドメインに分割する。そして、そのサブドメインに対して、共通性／可変性分析を実施する。共通性／可変性分析の結果、システム全体を新たな視点で見直す必要が生じることもある。その場合には、サブドメイン分割を再度やりなおすことになるだろう。共通性／可変性分析をサブドメインで集中して実施していくと、実装のための抽象が見え始めてくる。

ドメイン分析の主要なアクティビティ

  1. ビジネスドメインを特定すること（ドメインの範囲の決定）->ドメインスコーピング
  2. ビジネスドメインをサブドメインに分割すること->ドメインモデリング
  3. 各サブドメイン毎に抽象を定義すること->ドメインモデリング
kumamidori commented 9 years ago

サブドメインの再分割？　→　大きな問題領域では階層構造をとるということ。

例：グループチャットサービスの場合

最も粗いサブドメインリスト

（サブドメイン間には依存関係がある）。 もう一段階細かく見ていった場合のリスト。

p.96 「どのような共通性があるのかにより、ドメイン分割の方法が決定される」 とあるけれども、難しく感じます。。。DDDの集約は境界の例ですが、それよりも抽象的な、前段階の捉え方の話なのかな、と。

iteman commented 9 years ago

p.96 「どのような共通性があるのかにより、ドメイン分割の方法が決定される」 とあるけれども、難しく感じます。。。DDDの集約は境界の例ですが、それよりも抽象的な、前段階の捉え方の話なのかな、と。

最も優れたサブドメインは抽象のファミリを形成するような凝集度の高さと、結合度の低さを持ちます(サブドメインが業務の単位やパッケージの単位でないことに注意してください）。

サブドメインに分割するのは、共通性／可変性分析の前なので、これはあらかじめ主要な共通性／可変性分析が終わっていることを示します（なんということでしょう！）。しかし、実際にサブドメインに対して共通性／可変性分析を実施すると、それがこのような優れたサブドメインの特性を示さないことがわかってくることがあるかもしれません。そこで分析された結果を基にドメインを再編する価値がでてきます。

アプリケーションドメインとソリューションドメインの理解が進むと、より優れたサブドメインに分割できる可能性が高まると思います。

kumamidori commented 9 years ago

↑こちらありがとうございました。 7章 p.172 の後半以降とつながる話なのですね。

kumamidori commented 9 years ago

翻訳者の方によるコラム https://github.com/phpmentors-jp/mpdosaka/issues/4#issuecomment-98787916 に記述のあった

プレゼンテーション資料"Multi-Paradigm Design and Implementation in C++"の 翻訳

について、金澤様宛てに、もし今も残っていて公開可能の場合は読ませて頂きたい旨ご連絡し、資料を頂きました。こちらへアップしました。

https://github.com/phpmentors-jp/mpdosaka/tree/master/data