前回までの第十五章
コアドメインをどのように蒸留するか
１つは、設計の一部を競合との優位性を保つため、秘密にする必要があるとき、そこがコアドメインになる。というところは単純に選択できるところでしょう。
もう一つは、視点によって決まる。
例えば、汎用的な金銭に関するモデルは多くのアプリで必要になるかと思いますが、こちらはサブドメイン。一方為替に関するアプリなどでは、もっと複雑な金銭に関するモデルが必要になり、こちらはコアドメインになるでしょう。汎用的な金銭モデルと特化したドメインを分離してコアドメインを構成することになるでしょう。
このようにアプリが解決するビジネスのコンテキストによって選択するコアドメインは異なりますし、すぐにわからないかもしれません。
途中で、コアドメインだと思って実装していたモデルが実はそうではなかったということも。
コアドメインの識別はイテレーションを通じて進化させる必要があるということですね。
だれがコアドメインを実装するか
いうまでもなく、最も優秀なメンバーがコアドメインに当たるべき。
ただ、技術的に卓越したメンバーは大体技術的に大変なところに当たりたがるのが世の常。たとえば、インフラストラクチャ層の新しい技術とか。。。また、最も優秀なメンバーがドメインについての多くの知識がない場合、さらにコアドメインから離れていき、悪循環になりがち。
この悪循環を断ち切ることが大事です。
ドメインに関心がある優秀な技術者を集め、ドメインエキスパートが参加するチームを収集すること。
また、外部の専門家は当然呼ばない。ビジネス上最重要な箇所だからですね。
さらに同じ理由で、コアドメインを購入したり、制約のあるフレームワークを使うというのもなしですね。
今後さらに、蒸留のテクニックを読んでいきます。ドメインビジョン声明文、強調されたコア、凝集されたメカニズムなどなど。。。