第10回ドメイン駆動設計勉強会の感想 #dddosaka

第10回DDD勉強会で議論した内容をメモ。
自分が理解できたことだけを書いておく。

【参考】
第10回ドメイン駆動設計(DDD)読書会@大阪 - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

dddosaka/reading_ddd_report

第7回ドメイン駆動設計勉強会の感想　#dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第４回ドメイン駆動設計読書会の感想: プログラマの思索

ドメイン駆動設計に出てくる「モデル」とは何ですか？～第28回関西IT勉強宴会の感想: プログラマの思索

ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索

いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

第10回ドメイン駆動設計勉強会＠大阪 from akipii Oga

【1】15章「汎用サブドメイン」「隔離されたコア」

コアドメインは、ソフトウェアプロダクトラインのコア資産とほぼ同じ。
蒸留は、コア資産抽出の作業と同じ。

コア資産こそがそのモデル、そのシステムの中核となるドメインの塊。

すると、そのコアドメイン(コア資産)から、補助的な役割を持つドメインを分離して、コア資産の凝集度を高めることが重要になってくる。

【1-1】補助的な役割を持つドメインはいくつかある。
一つは、汎用ドメイン。
たとえば、フレームワークなどの開発基盤、アナパタやリファレンスモデルのようなモデルテンプレート、自動テスト、共通関数など。
「ドメイン駆動設計」の例では、タイムゾーンモジュールがあった。

他にも、会計や物理学は既にモデルとしてテンプレート化されているため、汎用サブドメインの範疇になる。

【1-2】他には、隔離されたコア。
「ドメイン駆動設計」の例では、P.437にあるように、輸送パッケージから、配送<<コア>>と物流、顧客、金銭<<汎用>>のドメインに分離していている。
コアドメインが配送<<コア>>であり、隔離されたコアが物流、顧客、汎用サブドメインが金銭<<汎用>>に相当する。

責務駆動設計の観点では、以下の点で整理される、という話もあった。

・配送<<コア>>：コアドメイン。実績に相当。「業務」に相当。
・顧客、物流：隔離されたコア(補助的なサブドメイン)。計画に相当。「能力」「潜在能力」に相当。

【1-3】「ドメイン駆動設計」を読んで面白いのは、「汎用サブドメイン」「隔離されたコア」 の注意点やリスクが興味深いところ。

汎用サブドメインは共通関数やモデルテンプレートが該当するので、開発チームの中で優秀なメンバーが割り当てられやすい。
すると、技術系の人間ほど、タイムゾーン変換や物理学のような限定可能な問題を楽しむ傾向があり、そういう問題に時間をかけすぎてしまう。
本来ならば、コアドメインの開発に注力すべきなのに、2級レベルの開発者をアサインして、プログラムがあまりきれいでない状況になってしまいがち。

また、XPのようなアジャイル開発では、アーキテクチャスパイクやゼロリリースのように、初期のイテレーションで、技術的アーキテクチャの妥当性を証明するように、補助的な汎用サブドメインを扱う周辺システムを構築したがる。
しかし、これでは、本来のリスク管理にはならない。
コアドメインを少しずつ作っていき、ドメインモデリングのリスクを下げていく方向に進まないから。

それゆえ、初版のシステムは、単純であってもコアドメインの一部を作らなければならない、と主張している。
この点は同感。

【1-4】また、「隔離されたコアを切り出すタイミングは、システムにとって重要な、巨大な境界づけられたコンテキストがあり、モデルの本質的な部分が大量の補助機能のせいでわかりにくくなった時」と「ドメイン駆動設計」に書かれているが、そのタイミングでは手遅れではないか、という質問もあった。

確かに、コアドメインがどんどん巨大になっていた事実に気づいた時には、リファクタリングしようにも本番稼働中なので手を入れられず、最終的には、既存ドメインを捨てて、新規システムへリプレースするしかない経験が多い。
隔離されたコアを抽出して修正すべきタイミングを見つけるのは、実際にはとても難しい。

議論の中では、一つの解決法として、CIのメトリクスで凝集度や結合度などのメトリクスを常時測定しておき、メトリクスの兆候がある閾値を超えるとか、メトリクスの怪しげな傾向を見つけたら、隔離されたコアを抽出するタイミングと判断することもあるね、という話もあった。

【1-5】「<<コア>>」「<<汎用>>」はステレオタイプ。
パッケージ名やクラス名に、「～コアクラス」と書くのは良くない。
「<<コア>>」「<<汎用>>」はタグのようなものだから、ステレオタイプにした方がいい。

【2】16章「責務のレイヤ」

・ポリシー、業務、能力のレイヤは、パッケージを横断した構造ではないか？

・「業務」はイベント、トランザクションに相当。
・「能力」「潜在能力」はマスタ、リソースに相当。

・顧客が「能力」に相当する理由：
→輸送会社の例では、顧客はリピータ中心のため、顧客はビジネス上の資源であり、何度も活用する情報である。
　例：ダイレクトメールを客に送って、輸送の注文を促す

・逆に、一見の顧客の場合、顧客は「業務」でとらえられる。
　一見の顧客なら、顧客の情報をマスタとして持つ必要がない。
　トランザクションテーブル(例：輸送、配送、注文)に顧客の情報が含まれて、混在しているだろう。
　トランザクションテーブルに混じっている顧客データは、再利用される対象ではない。

・運送行程クラスは「能力」層なのに、「望ましい(isPreferred)」というメソッドがあり、唯一調和していない。
　そこで、「ドメイン駆動設計」では、運送行程クラスの「望ましい(isPreferred)」を「経路偏向ポリシー」クラスへ外出しして、「ポリシー」層に抽出している。

・新しい機能「特定の危険物に対しては、経路選択時に制限が適用される」をドメインモデルに反映する場合、従来のクラス設計では、「危険物経路サービス」を作ったとしても、呼び出しクラスになる「貨物」クラスにロジックが集中し過ぎて良くない。
　そこで、「ドメイン駆動設計」では、「経路選択サービス」に危険物の経路判断の呼び出しロジックを移動し、貨物クラスから切り離す。

・「ドメイン駆動設計」における「～サービス」クラスは、ユースケースに相当する。
　ユースケースに該当するサービスクラスが、業務ロジックのトリガーになっている。