前回までの第十五章
コアドメイン1
コアドメイン2
汎用サブドメイン
ドメインビジョン声明文
強調されたコア
凝集されたメカニズム
隔離されたコア
抽象化されたコア
蒸留最後のパターン。
サブドメインを分割し、モジュールが増えていくと、サブドメイン間の相互作用が曖昧になったり、複雑になったりする。
そこで、分割を垂直ではなく、水平にすることを検討します。
つまり、多態性を利用してインターフェースに括りだす。
例えば、「注文」モデルには、キャンセル後の注文、配送完了後の注文についての情報も含まれていて、大きくなりがち。そこで、「注文」を抽象化し、「キャンセル後注文」「配送完了後注文」など多態性を利用することができます。
こうすることによって、コア自体が整理されるだけでなく、抽象化されたコアを参照するドメインもその相互作用について簡潔に表現できるでしょう。
注意点としては、
- 機械的にやらないこと。抽象化するためには、概念が果たす役割についての深い理解が必要になります。
- 相当な量の再設計が必要になる。前回の隔離されたコアでもそうでしたが、モデルの本質的な部分がわかりにくくなってきたときに行うものなので、当然相当な量の再設計が必要になります。
隔離されたコアも抽象化されたコアもある程度大きくなったモデルに対しても行われるもの、モデルが成長すると、なかなかその構造を変更していくのは大変かもしれません。
ただ、ここでやるかやらないかでその後のやりやすさが大きく変わってくるかもしれませんね。
蒸留落ち葉拾い
深いモデルの蒸留
ここまで、蒸留について見てきましたが、汎用サブドメインや隔離されたコアからコアを蒸留するという意味だけではなく、コアドメインをリファクタリングして改良することも含まれています。
深いモデルは、ドメインの最も本質的な側面を蒸留してシンプルな要素にする。さらに先の蒸留と合わさって、アプリケーションの重要な問題を解決できます。
リファクタリングの対象を選ぶ
リファクタリングをどこからするか迷う時、つまり、うまく分解されていない巨大なシステムのどこから手をつけるかという話題。
- どこからでも
- 困ってるところから
Evansはどちらも否定しています。
- コアか、コアと補助的要素の関係を含むものであれば、リファクタリングする
- コアドメインの括りだし、コアの隔離の改善、補助的なサブドメインから不純物を取り除き、汎用サブドメイン化。これを最初に集中してやる。
迷ったらコアドメインからということですね。