前回までの第十五章

抽象化されたコア

蒸留最後のパターン。

サブドメインを分割し、モジュールが増えていくと、サブドメイン間の相互作用が曖昧になったり、複雑になったりする。

そこで、分割を垂直ではなく、水平にすることを検討します。
つまり、多態性を利用してインターフェースに括りだす。

例えば、「注文」モデルには、キャンセル後の注文、配送完了後の注文についての情報も含まれていて、大きくなりがち。そこで、「注文」を抽象化し、「キャンセル後注文」「配送完了後注文」など多態性を利用することができます。

こうすることによって、コア自体が整理されるだけでなく、抽象化されたコアを参照するドメインもその相互作用について簡潔に表現できるでしょう。

注意点としては、
1. 機械的にやらないこと。抽象化するためには、概念が果たす役割についての深い理解が必要になります。
2. 相当な量の再設計が必要になる。前回の隔離されたコアでもそうでしたが、モデルの本質的な部分がわかりにくくなってきたときに行うものなので、当然相当な量の再設計が必要になります。

隔離されたコアも抽象化されたコアもある程度大きくなったモデルに対しても行われるもの、モデルが成長すると、なかなかその構造を変更していくのは大変かもしれません。
ただ、ここでやるかやらないかでその後のやりやすさが大きく変わってくるかもしれませんね。

ここまで、蒸留について見てきましたが、汎用サブドメインや隔離されたコアからコアを蒸留するという意味だけではなく、コアドメインをリファクタリングして改良することも含まれています。

深いモデルは、ドメインの最も本質的な側面を蒸留してシンプルな要素にする。さらに先の蒸留と合わさって、アプリケーションの重要な問題を解決できます。

リファクタリングをどこからするか迷う時、つまり、うまく分解されていない巨大なシステムのどこから手をつけるかという話題。

Evansはどちらも否定しています。

迷ったらコアドメインからということですね。