前回までの第十五章
汎用サブドメイン
補佐役を果たすもので、汎用的な役割だが、システムを機能させて、モデルを完全に表現するためには欠かせないものです。
ほとんどのビジネスで必要になる概念を抽象化したもの。
ただし、このようなモデルは専門的な知識をとらえることなく、複雑さを付け加えるだけの部分もあります。
汎用サブドメインの例としては、組織図や売掛金、経費元帳、財務などの会計モデル、タイムゾーンなどなど。
こうした、プロジェクトにとって動機になっていない、サブドメインをコアドメインと分けて考え、サブドメインの優先度を下げ、コアドメインに開発者を割り当てること。
コアドメインの解決策
- 既製品を使う・・・たとえば、認証、認可のモデルにSpringSecurityを使うとか。使うには事前に時間をかけて評価して、理解する必要がありますが、成熟度も高く、使わているので安定しています。
- 公表されている設計やモデル・・・アナリシスパターンや公表された言語を使用する。
- アウトソーシングする・・・ コアドメインを流出させずに発注することが大事ですが、コアドメインに集中できます。ただし、インターフェイスなどの重要な側面についてコアチームが時間を割く必要があります。
- 自社で実装する・・・現状はこれが選択されるでしょうとEvansが言っています。それでもコアドメインモデルから切り分けることには価値があります
将来的には、多くの汎用的なモデルがフレームワークや、公表されたモデル・アナリシスパターンとして手に入るようになるでしょうとEvansは予言していますが、実際どうでしょうか？
SpringFrameworkは結構ここに力を入れている気がします。
SpringSecurityではモデルも公開されていますし、開発側が比較的自由にいじることもできますね。
汎用サブドメイン＝再利用可能ではない
ここは大事なところですね。再利用性を考慮していては、蒸留のコアドメインに集中するという動機から外れてしまいます。
ただし、
汎用的な概念の範囲内に収めるということに関しては厳格でなければならない(第十五章 より)
ということは注意しておきたいですね。