HIGHLIGHTED CORE (p.417) †
要約 †
HIGHLIGHTED CORE （強調されたコア）
DOMAIN VIDION STATEMENTによってCORE DOMAINを概観できるようになるが、それだけでは不十分。
＊＊＊
【問題サマリ】
- コアドメインの構成要素について、チームメンバーが分かっていたとしても、他の人もそうとは限らないし、同じメンバーであっても後になったら分からなくなるかもしれない。モデルのポイントを拾い上げる作業は骨が折れるものだし、モデルに対する総括的な知識も必要だから、CORE DOMAINは分かりやすい方がいい。
- コードの構造を変えることはCORE DOMAINを見やすくするための理想的な方法ではあるが、短期的に見た時に常に現実的である訳ではない。実際問題、そういったコードの変更にはCORE DOMAINが見やすくなっていないと難しいものであるのだが、今まさにそれが見えない場合の話をしているのだ。
【問題の解決方法についての説明】
- GENERIC SUBDOMAINのようなモデル構造の変更によって、MODULEに語らせることができるようにはなるが、CORE DOMAINについて語る方法としては抽象的すぎる。
- もう少し簡単な方法はないものか。物理的にコアを分けられないかもしれないし、現行のコードが分かりにくいけれど、リファクタリングのためにコアが見たいということもあるかもしれない。実際、後行程になっても、丁寧に選択された図やドキュメントが心理的な錨（"mental anchor point"）にもなるし、エントリポイントにもなるのだ。
- このテクニックは、UMLをガッチリ書くプロジェクトにも、XPのようにそうでもないプロジェクトにも有効である。
- CORE DOMAINを分かりやすくできれば、どんな方法でも良いのだが、類型を２つ。
凝縮されたドキュメント †
- CORE DOMAINについて記述し、説明するために別のドキュメントを作ることがある。凝縮されたドキュメントは完全な設計ドキュメントでなくてよい。
Therefore:
- 非常に短いドキュメント（３〜７ページのざっくりしたもの）を作りなさい。そこでCORE DOMAINについてと、コア要素との基本的なインタラクションについて説明しなさい。
- ドキュメントを分けるリスクはここでもある。
- メンテナンスされないかもしれない。
- 読まれないかもしれない。
- 重複してしまうことで複雑さを切り分けるという当初の目的から外れるかもしれない。
- こういったリスクを避けるためにはとにかくざっくりしたものをつくること。
- 技術者ではない人にも分かるように書くこと。そして、共通認識資料およびガイドとして使いなさい。
目印のつけられたコア †
- とある有名な保険会社のプロジェクトに入った時の話。コンサルにド偉い値段で売りつけられた２００ページのドキュメントを「ドメインモデル」といって渡された。抽象度も品質もバラバラなのだがどこから手を付けたものか。２００ページだぜ？
- 文化的には抽象度の高いフレームワーク構築を好むようだったが、保険業務とは関係がない。
- 直感的には小さなCORE DOMAINを切り出して、リファクタリングしながら進めていきたかったが、お客さんはいやがった。自分より遥かに単価の高いコンサル様の成果物だから。しかし、小さなCORE DOMAINのビジョンを共有して、そこに全員の神経を集中させる必要があった。
- リファクタリングするかわりに、ビジネスエキスパートの助けを借りながら、本質的なセクションをピックアップすることができた。
- プロトタイプをここからはじめ、単純なアプリケーションを作成した。
- １キロ弱の再生紙が、いくつかのページタブと黄色の蛍光ペンによって業務的な価値を持った。
- これは紙に限ったことではなく、UMLならばステレオタイプが、コードならばコメントが使える。
Therefore:
- モデルの主要なリポジトリの中で、CORE DOMAINの各要素に目印をつけなさい。その時にその役割を明らかにしようと躍起になる必要は無い。何がコアで何がそうでないかがすぐ分かるようにしなさい。
- こうやってCORE DOMAINがはっきり見えるようにするのに、労力もメンテナンスの手間も大してかからない。
プロセスツールとしての凝縮されたドキュメント †
- 理論上、XPでは誰もがコードを変更できる。しかし実際にはそう簡単に変えてはいけないこともある。インフラ層では修正のインパクトが明確だが、ドメインレイヤではそうでもない。
- CORE DOMAINという概念によってこのインパクトを明確にすることができる。CORE DOMAINのモデルに対する変更の影響は大きいが、広く使われている一般的な要素であればそうでもない。
- 凝縮されたドキュメントをガイドとして使いなさい。ドキュメント自体の変更が必要であれば、他の人に相談しなさい。
- 凝縮されたドキュメントがCORE DOMAINの本質を描き出しているならば、モデルの変更がどの程度重要なものかということを示す指標になる。モデルやコードの変更が凝縮されたドキュメントに影響を及ぼすならば、他のチームメンバーにも相談する必要がある。変更したら、すぐに他のメナーに知らせ、ドキュメントの新しいバージョンを配布しなければならない。コアの外部や凝縮されたドキュメントに含まれない詳細に関するものであれば、相談や通知をする必要がなく、他のメンバーは自分の作業の中で気がつくことになる。そうすることで開発者はXPが提示する自律性をあますことなく享受できる。
＊＊＊
VISION STATEMENTとHIGHLIGHTED COREは情報を与えてはくれるが、モデルやコードそれ自体を変更するものではない。それに対して、GENERIC SUBDOMAINSを区切ることで、紛らわしい要素を物理的に取り除くことができる。次のパターンではモデルの構造をかえることでコアドメインをより見えやすく、扱いやすくする方法を見ていく。。。
担当者のつぶやき †
- 言っていることが非常に分かりやすいパターンだったと思います。
- 要約すれば、「コアドメインがはっきり分かるようなドキュメントを作りなさい。」やり方は２つあって：
- 簡単なものを別に作るか
- ドキュメントの中で目立つようにするのか
- この時、「システム全体の見取り図」ではなく、重要なドメインモデルに特化した資料が求められている点には注意が必要かと思われます、
みんなの突っ込み †
