Core Domain (P?) †
本文 †
大きなシステムを設計する際、複雑で必須の構成要素が多くあるため、ドメインモデルの本質は曖昧にされ無視されがちだ。
理解しにくいシステムは変更が難しい。変更の影響は予期し難い。開発者は自分の担当外では迷子になる。これは、特に新しい人が入ったときはそうなるが、確立したメンバーも、コードが明確に表現され整っているのではない限り、苦労する。
こうなると、専門化が進む。もし開発者を特定のモジュール担当に閉じるのであれば、他の人への知識の移転はさらに少なくなる。このような作業の分割は、システムの統合を難しくし、作業割当の柔軟性を失わせる。
これらは、理解困難な設計の結果だが、さらにドメインの大きな絵を失う危険もある。
設計の全部分を等しく洗練させるということではない。優先付けが必要だ。ドメインモデルを資産とするには、モデルのコアの部分が滑らかで、アプリケーションの機能の作成時に十分に活用されるようにする必要がある。非常に熟練した開発者は、特定のドメインの知識無しに理解可能な、技術的インフラもしくは限定されたドメイン問題に引き寄せられる傾向がある。
システムのそういう部分は、コンピュータサイエンスにとっては興味深く見え、伝達可能なプロフェッショナルなスキルを構築し、よりより経歴書の材料を提供してくれそうに見える。
そのため、特化したコアの部分、アプリケーションを差別化し、ビジネス上の資産となる部分、については通常スキルの劣った開発者によって組み立てられることになる。開発者は、DBAと一緒に、データスキーマをつくり、モデルにある概念的な力に基づくことが全くなく、機能ごとにコードを書いていく。
貧弱な設計もしくは実装は、どれだけ技術的インフラやサポートされている特徴がよくても、ユーザに何も訴えないアプリケーションとなる。この問題は、プロジェクトに、全体の設計と様々な部分の相対的な重要性についての絵が欠けているところに原因がある。
最も成功したプロジェクトに参加したことがあるが、最初この問題に苦しめられた。ゴールは非常に複雑なローンシステムを開発することであったが、非常に能力のある人はDBマッピングレイヤーやメッセージングのインターフェースに喜んで取り掛かり、ビジネスモデルについては、オブジェクト技術に未熟な開発者の手の内にあった。
例外が一つあるが、経験あるオブジェクト指向開発者がドメインの問題に取り組み、長命のドメインオブジェクトにコメントを付加する方法を考案した。これらのコメントにより、トレイダーは、ある決定についての根拠を見ることができるようになる。彼はまた、洗練されたユーザインターフェースを作り、そのコメントモデルの柔軟な特徴に対して直観的にアクセスできるようにした。これらの特徴は、有用でよく設計されており、実用に組み入れられた。
残念ながらそれらは抹消的なものだった。この有能な開発者は、彼の興味のある、一般的なコメントについてモデルをし、綺麗に実装し、ユーザに渡した。一方で、無能な開発者は、ミッションクリティカルなローン・モジュールを理解不能な混乱した状態にし、プロジェクトは回復不能なところまで陥った。
計画段階で、人的リソースを、モデルと設計の最も重要な点に配置する必要がある。そのためには、計画と開発の段階で、全員に理解してもらう必要がある。
これらの、アプリケーションの目的の中心かつ独特なモデルの部分がCORE DOMAINを構成する。CORE DOMAINは、システムに対して最も価値あるものが加えられる場所である。
Therefore
- モデルを煮詰めよ。
- CORE DOMAINを見つけ、それを支える大量のモデルやコードから簡単に区分する方法を提供せよ。
- 最も価値があり特別な概念を浮き彫りにせよ。
- COREは小さくせよ。
- トップクラスの才能のある人をCORE DOMAINに適用せよ（それに沿って採用せよ）。
- COREに注力し、システムのヴィジョンを満たすのに必要な、深いモデルを発見し、柔軟な設計をせよ。
- コアをサポートする他の部分への投資を正当化せよ。
CORE DOMAINの蒸留は簡単ではないが、ある簡単な決定へ導く。
COREを独特にすることに注力し、残りの設計をできるだけ一般的なものにすること。もし設計の中で、他との競合上秘密にしておきたい部分があるなら、それがCORE DOMAINとなる。またもし、二つの望ましいリファクタリングの間で選択する必要がある場合、CORE DOMAINに最も影響するものをまず選択すること。
＊ ＊ ＊
この章のパターンは、CORE DOMAINをより見やすく、使いやすく、変更しやすくしてくれる。
COREを選択する †
モデルの中で、ビジネスドメインとビジネス上の問題を解決する部分について見てみる。
選ばれたCORE DOMAINはあなたの見解に依存する。例えば多くのアプリケーションは、様々な通貨や為替レートを表すことのできる一般的な金銭のモデルを必要とする。一方、為替取引をサポートするアプリケーションはより精密なモデルを必要とし、それがCOREの一部と見なされるかもしれない。そういう場合でも、金銭のモデルは非常に一般的かもしれない。
ドメインへの洞察が深くなれば、蒸留のプロセスは、一般的な概念を切り離し、CORE DOMAIN内の特別な面だけを留めることによって進められる。
一つのアプリケーションのCORE DOMAINは他のアプリケーションの汎用的なコンポーネントとなる。一つのプロジェクトを通して、あるいは通常一つの企業を通して、一貫したCOREが定義されうる。
設計の他の部分でもあるように、CORE DOMAINの識別はイテレーションを通じて進む。特別な関連の重要性は最初には明確ではないかもしれない。最初に中心と思われたオブジェクトは補助的な位置づけに変わるかもしれない。
以下のセクションでの議論、特にGENERIC SUBDOMAINSでは、これらの決定へのガイドラインをより多く提供する。
だれがその作業をするか？ †
最も技術的に卓越したメンバーは、めったにドメインの知識を持っていない。そのため、彼らを支持コンポーネントに割り当て、ドメインの知識を構築する作業から離してしまう悪しきサイクルを続けることになる。
このサイクルを破り、長期間継続しドメインの知識の宝庫となることに興味がある強力な開発者をマッチさせるよう組み立てなおすことが重要だ。ドメインの設計は真剣に取り組むなら面白く、技術的にもチャレンジングな仕事で、そう見る開発者もいる。
CORE DOMAINの作成を短期の外部の専門家に行ってもらうのは実用的ではない。なぜならチームはドメインの知識を蓄積する必要があるからだ。一方、教育・助言役の専門家であれば、非常に価値がある。
同様の理由で、CORE DOMAINは購入はできないだろう。業界特有のモデル・フレームワークを作成する努力がなされており、際立った例としては、半導体産業のSEMATECH's CIMフレームワークや、IBMのSan Franciscoフレームワークがある。非常に魅惑的なアイデアだが、これまで結果は、データ交換のためのPUBLISHED LANGUAGESなどを除いて、有力ではない。Domain-Specific Application Frameworks (Fayad and Johnson 2000) の本に、この技術の最新状況が書かれている。この分野が進めば、より実用可能なフレームワークができるだろう。
たとえそうであっても、注意した方がいい重要なわけがある。カスタマイズしたソフトウエアの最も重要な価値は、CORE DOMAINを完全にコントロールできるところから来る。
よく設計されたフレームワークは、ハイレベルな抽象化を提供し、より一般的な部分の開発を省き、COREに集中させてくれる。しかしもしあなたがそれ以上に制限されるのであれば、以下の３つの可能性がある。
- あなたはソフトウエア資産のエッセンスを失いつつある。CORE DOMAINにある制限的なフレームワークから手を引くこと。
- フレームワークで扱っている領域が考えているほど中枢ではないこと。CORE DOMAINの境界を、モデルの真に独特の部分へと描き直すこと。
- CORE DOMAINに特別な要求がない。ソフトウエアを購入して統合するなど、よりリスクの少ない方法を考慮すること。
いずれにせよ、独特のソフトウエアを作成するには、安定したチームで特別な知識を蓄積し、リッチなモデルに噛み砕いていくことだ。近道はない。魔法の弾丸もない。
担当者のつぶやき †
- 有能な人を技術的に難しい部分に割り当ててしまい、コアドメインが手薄になってしまうというのはよくありました。ただ技術的に難しい部分にスキルの低い人を割り当ててもなかなか結果が出てこないのでこの辺はどうなんでしょう？
みんなの突っ込み †
- Deep Model と Core Domainの違いって？ -- 池田?
