前回までの第十五章

凝集されたメカニズム

汎用サブドメインとはまた異なる、コアドメインと区別するもの。

「何が(what)」と「どのように(how)」を分離するのがカプセル化の仕組みですが、「どのように(how)」が肥大化し、複雑化することがあります。

問題を解決するためのアルゴリズムを提供するメソッドが大量に存在すると、問題を表現するメソッドがわかりづらくなります。

そこで、そのような凝集された部分を抜き出すことで、残りが理解しやすくする。
これが、コアドメインを蒸留する手法の１つです。
凝集されたメカニズムはフレームワーク化すると使いやすくなります。

書籍の例では、組織図で用いられる[グラフ]のメカニズムをフレームワーク化していました。
注意する点としては、処理だけに焦点をしぼって、ドメインに関する部分を混ぜないようにすることです。

個人的に直近のプロジェクトで経験したところで、使えるなと思ったのは、elasticsearchでの検索に使用するモデルからelasticsearchのqueryを構築するためのメカニズムをフレームワーク化すること。

ここを素直に検索用のモデルを構築すると、書籍にあるような仕様オブジェクトのようなモデル(andモデルとかrangeモデルとか)を作ることになるのですが、そこをフレームワーク化することで、本質的な検索仕様が蒸留されるかもと思いました。

汎用サブドメインはビジネスの中心であるドメインから離れてはいるけど、表現力豊かであるべきモデルです。
凝集されたメカニズムはドメインを表現するのではなく、あくまで「処理」の問題を解決するためにあります。

コアドメインと凝集されたメカニズムを分離しやすくするためには、第十章で読んだ意図の明白なインターフェースなどを活用した、しなやかな設計になっていることが大事です。

「何が(what)」と「どのように(how)」を分離するためのテクニックなので、何となくわかりますね。