前回までの第十五章
コアドメイン1
コアドメイン2
汎用サブドメイン
ドメインビジョン声明文
強調されたコア
凝集されたメカニズム
汎用サブドメイン、凝集されたメカニズムから蒸留し、コアドメインが浮かび上がってきましたが、ここで本丸登場です。残ったモデルをさらに蒸留していきます。
隔離されたコア
モデルをさらにリファクタリングして、コアの概念を補助的な役割を果たすサブドメインから分離し、別のパッケージに入れることで、コアの凝集度を高め、他のコードへの結合を低くします。
補助的な役割を果たすモデルは、はっきりと定義されていないものもあるかもしれないし、分離したのち、コアでないクラス群との関係がさらに曖昧で複雑になることもあるかもしれない。それでもコアと分離して、コアを分離することが大事です。
それは、ソフトウェアの価値がコア、ビジネスの本質的な部分にあるからですね。
やり方
- コアを識別する(コアサブドメイン)。ドメインビジョン声明文や蒸留ドキュメントから識別することもできる。
- 関連クラスを、それを関係づけている概念に由来する新しいモジュールへ移動する。
- リファクタリングして、概念を直接表現していないデータと機能を切り離す。
- 他のモジュールとの関係を最小限におさえて明確化する
- 1から繰り返し
いつやるか
システムにとって重要な、巨大な境界づけられたコンテキストがあり、モデルの本質的な部分が大量の補助的な機能のせいでわかりにくくなってきたとき(第十五章より)
貨物輸送モデルの例
ここまで読んでも、理解はできるけど、いざ実践となるとどこをコアとするか判断するのは難しそう。
ということで例を読みます。
この例はコアに駆り立てるほどには入り組んでいないかもしれないが、・・・このモデルが非常に複雑で容易に解釈したり全体として処理したりできないものとして扱って欲しい。
なので、やはり動機は巨大になってきて、モデルの本質的な部分がわかりにくくなってきたときということですね。
通常、まず見るべきは「最終的な利益」
しかし、本当に調べるべきはドメインビジョン声明文
営業部門向けに設計されたものではない
ということで、例えば「請求」は、コアではなく、補助的な役割。
使用するのは、現場にいるその会社の担当者
焦点を合わせるべきなのは、貨物の取り扱い、すなわち、顧客の要件に従って貨物を配送することだ。
とうことで、「配送」パッケージに隔離されたコアを抽出していきます。
という流れです。
蒸留
ここまでコアを蒸留していくパターンを読んできましたが、これらは最初からそのように設計できるということではなく、コアが大きくなってきた、本質的なものが見えなくなってきたとき、リファクタリングの結果できることです。
何日か前にアドバイスをいただいたのですが、蒸留はボトムアップのプロセスということ。
なので、何度も見直されるし、コアの元となるドメインビジョン声明文も蒸留ドキュメント、さらにはインセプションデッキも作って終わり、トップダウンで作成されるものではなく、変更されていくもの、ボトムアップで成長させていくものとして扱うことが大切ですね。