DDD
担当：佐藤匡剛
COHESIVE MECHANISMS (p.422-426) †
要約 †
COHESIVE MECHANISMS （凝集されたメカニズム）
【問題についての説明】
- メカニズムのカプセル化は、OOの標準的な原理。複雑なアルゴリズムをメソッドの中に隠して、意図の明白な名前を付けることで「何を（what）」と「いかに（how）」を分離できるが、自然と限界点に到達する。
【問題サマリ】
- 計算の複雑さがあるレベルに達すると、概念的な「何を」をメカニズム的な「いかに」が圧倒してしまう。アルゴリズムを提供するメソッドが多くなって、問題を表現しているメソッドを分からなくしてしまう。
【問題の解決方法についての説明】
- 手続が多くなってしまうのは、モデルに問題がある兆候。なので、まずはドメインリファクタリングして、計算メカニズムがシンプルになるようなモデルを探すこと。その上で、メカニズムのある一部分は凝集性が高いという知見が得られることがある。そうした凝集性の高い部分は、抽出するとよい。
Therefore:
【解決方法サマリ】
- 概念的なCOHESIVE MECHANISMを軽量のフレームワークとして分離せよ。とくに形式化されてるものや、書物などにまとめられているようなアルゴリズムに注目。これによって、ドメインの他の部分は問題（what）に集中でき、解決法（how）はこの軽量フレームワーク側に委譲される。
【結果、実装上の検討事項、サンプル】
- こうしてメカニズムを分離することで、CORE DOMAINはより宣言的スタイルになっていく。
- 標準的なアルゴリズムや形式化はよく研究されているので、安心して実装できるし、それを知ってる開発者に任せることもできる。標準的なものでなく、自分で新たなメカニズムを作り出す場合は、フォーカスを狭く保つこと。
- 責務の分離：CORE DOMAIN、GENERIC SUBDOMAIN＝事実、ルール、問題 ⇔ COHESIVE MECHANISM＝ルールの解決、計算
Example: A Mechanisms in an Organization Chart （例：組織図におけるメカニズム） †
- ある組織図のモデルを必要としたプロジェクトで、このプロセス（COHESIVE MECHANISMS）を経験した。この組織図モデルは承認や権限などの所在を問い合わせることができるもので、グラフ形式のルールやアルゴリズムを適用して解決できるものだった。
- 下請会社（subcontractor）がグラフ探索フレームワークをCOHESIVE MECHANISMSとして実装した。このフレームワークでは、標準的なグラフ理論の用語やアルゴリズムが用いられていて、その内部実装はINTENTION-REVEALING INTERFACEによって隠蔽されている。
- こうして組織図モデルは、標準的なグラフ理論の用語を用いて、人とその関係がノード（node）とアーク（arc）によって表現された。フレームワーク内のメカニズムによって、任意の2人の間の関係を容易に求めることができるようになった。
- もしこのメカニズムをドメインモデルに組み込んでいたら、以下2つのコストが発生しただろう。
- モデルが特定の解決方法に縛られてしまい、将来の選択肢を狭めていた。
- 組織図のモデルは非常に複雑でグチャグチャになっていた。
- メカニズムをモデルから切り離すことで、モデルをきれいに保つと同時に、信頼できるメカニズムの基盤を得ることができた。
- もう1つの例は、SPECIFICATIONオブジェクトのフレームワーク。基本的な比較、結合の演算を提供するもの。
＊＊＊
【実装上の課題（解決方法のセクションに収まりきらない場合のみ、ここへ外出し）】
GENERIC SUBDOMAIN Versus COHESIVE MECHANISMS （GENERIC SUBDOMAIN 対 COHESIVE MECHANISMS） †
- GENERIC SUBDOMAINSもCOHESIVE MECHANISMSも同じモチベーション（CORE DOMAINをシンプルに保つ）から来ているが、責務の性質が異なる。
- GENERIC SUBDOMAINS ･･･ チームがドメインをどう見るかのモデル（CORE DOMAINと同じで、重要かそうでないかの違いだけ）
- COHESIVE MECHANISMS ･･･ ドメインは表現せず、面倒な計算を解決するだけ
- 【名言】計画する（propose）のはモデル、処理する（dispose）のはCOHESIVE MECHANISMS。（参考：Man proposes, God disposes. : 《諺》計画するのは人、成敗をつけるのは神。）
- 実際には、両者の境界は少なくともすぐには判明しない。何度もリファクタリングを繰り返す中で、COHESIVE MECHANISMSになることもあればGENERIC SUBDOMAINSになることもある。
When a MECHANISM Is Part of the CORE DOMAIN （COHESIVE MECHANISMSがCORE DOMAINになるのはいつか） †
- 常にMECHANISMSはCORE DOMAINから排除すべきだが、唯一の例外はMECHANISMそれ自体が独自で、ソフトウェアの中核である場合。
- 例1：配送計画アプリケーションの目玉となる効率的なスケジューリングのアルゴリズム
- 例2：投資銀行の超極秘リスク評価アルゴリズム
- ただし、MECHANISMをCORE DOMAINにするかどうかは、費用対効果の分析に基づいて判断すべし。
Example: Full Circle: Organization Chart Reabsorbs Its MECHANISM （一回転：組織図が再びメカニズムを取り込む） †
- 実は、我々が組織モデルを完成させた一年後、別の開発者がグラフフレームワークを再びモデルに取り込んだ。彼らには、モデルとMECHANISMとの分離が、自然だと思わなかったらしい。その代わり、ENTITIESに直接振る舞いをくっつけた。しかし、宣言的なpublicインタフェースは保持し、MECHANISMのかぷせる化は保った。
- こういう一回転はよくあるけれども、スタートに戻った訳ではない。そのときは、もっと深いモデルが得られているのだ。
【結果として導き出される文脈、次のパターンへの導入】
Distilling to a Declarative Style （p.426-427） †
- 蒸留（distillation）の価値は、エッセンスを抽出すること。簡潔で表現力ある言語のサポートがあれば、CORE DOMAINは宣言的スタイルになりうる。
- 優れたCOHESIVE MECHANISMS ＝ INTENTION-REVEALING INTERFACE ＋ ASSERTIONS ＋ SIDE-EFFECT FREE FUNCTIONS。結果としてCORE DOMAINにブレイクスルーが起こり、深いモデルになったときに、桁外れの報酬が得られる。
- 深いモデルはしなやかな設計と対になるが、しなやかな設計が成熟すると、クライアントコードは宣言的スタイルになり、蒸留される。
- GENERIC SUBDOMAINSとCOHESIVE MECHANISMSによって、CORE DOMAINをよりフォーカスされたモデルにすることができるが、COREにしか置き場所がないものもある。次のSEGREGATED COREでは、直接的にCORE DOMAINを縁取るアプローチを取る･･･
担当者のつぶやき †
みんなの突っ込み †
