【要約】サブドメインの分け方とその意味について

DDD関連の記事を紹介してみたい。

今回は、Vladikkさんの2018年の記事。タイトルは「DDDの基本を再考する」だが、内容としては「サブドメインの分類方法」について述べられている。

今回はこの記事を要約してみよう。(日本語での要約の許可をVladikkさんからもらっています)

※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします

前段に書かれている内容は基本的なものだ。

  • ドメインが事業領域を意味する

  • サブドメインはさらに細分化された事業領域

サブドメインには種類がある。

  • 汎用サブドメイン

    • 一般的な問題を解決することで、コアドメインと支援サブドメインをサポートする

  • 支援サブドメイン

    • コアドメインをサポートするためのサブドメイン

  • コアドメイン

    • 重要なビジネス価値を提供する。競争優位性を持つかどうかが決まる領域

後段は割とVladikkさん独自の観点での解説がある。

Sidenote: Domains Vs. Subdomains(ドメイン対サブドメイン)

企業の事業の枠組みをドメイン、特定のビジネス領域をサブドメインと呼ぶとのこと。

サブドメインがドメインに内包されていることがわかりやすい表現だと思う。

Sidenote: Assessing Complexity(複雑さの見極め)

この部分では、サブドメインの分類をビジネスロジックの複雑さに基づいて行う方法について説明している。シンプルなビジネスロジックと複雑なビジネスロジックを区別する具体的な基準は示されていないが、いくつかのヒューリスティック(経験則)が提示されている。

他にも、アルゴリズムの複雑さ、ビジネスルールの有無、コードの循環的複雑度などが複雑度の指標として挙げられている。また、サブドメインの複雑さは相対的であり、企業のニーズに大きく依存すると指摘されている。

Easy Categorization(簡易的なカテゴリ分け)

サブドメインの簡易的なカテゴリ分けの方法が記されている。

質問が3種類ある

  • Can solution be bought/adopted? / 競争優位を損なうことなく、ソリューションを購入・採用できますか?

    • Yesなら汎用サブドメイン、Noならコアドメイン

  • Will it jeopardize the business? / そのソリューションはビジネスにリスクをもたらすか?

    • Yesならコアドメイン、Noなら汎用サブドメイン

  • How complex is the Busisness Logic ? / ビジネスロジックはどの程度複雑か?

    • Yes(複雑)ならコアドメイン、No(シンプル)なら支援サブドメイン

文章での説明も直感的でないし、フローチャート図も直感的ではないと思ったので擬似コードにしてみた。

(そのソリューションを購入または採用できるか, そのソリューションはビジネスにリスクをもたらすか, ビジネスロジックは複雑か) match {

case (いいえ, はい, _) => コアドメイン() // ビジネスにリスクをもたらし、ソリューションを購入または採用できない場合

case (いいえ, いいえ, はい) => コアドメイン() // ビジネスロジックが複雑で、ソリューションを購入または採用できない場合

case (_, いいえ, いいえ) => 支援サブドメイン() // ビジネスにリスクをもたらさないが、ビジネスロジックが単純な場合

case _ => 汎用サブドメイン() // それ以外の場合

}

この式は以下のように要約できる。

  1. コアドメイン:ビジネスにリスクをもたらし、かつソリューションを購入または採用できない場合、またはビジネスロジックが複雑でソリューションを購入または採用できない場合、コアドメイン戦略を採用する

  2. 支援サブドメイン:ビジネスにリスクをもたらさない、かつビジネスロジックが単純な場合、支援サブドメイン戦略を採用する

  3. 汎用サブドメイン:上記のいずれの条件にも当てはまらない場合、汎用サブドメイン戦略を採用する

Aligning Business and Technical Complexities(ビジネスと技術的な複雑さの調整)

上記のサブドメインの分類方法によって、技術的な解決策の複雑さとビジネスの複雑を調整できる、としている。

  • コアドメインでは、複雑さに対処するためにドメインモデルパターン(Event Sourcing含む)を使う

  • 支援サブドメインでは、シンプルな解決策を講じる。手段はトランザクションスクリプトやアクティブレコードパターンでもよい。ビジネスを危険にさらすことなくアウトソースできるサブドメイン

  • 汎用サブドメインは自分たちで実装するよりも調達(購入や採用)するほうが安価

つまり、モデルの複雑度とビジネスの差別化度合いでサブドメインの分類を考える、ということのようだ。

---

Vladikkさん独自の観点でのサブドメインの分類方法を紹介した。サブドメインの選択はビジネスと技術的な複雑さを調整するための重要な要素ということがよくわかる記事だった。ご参考までに。

併せて読みたい

@j5ik2o
歳をとっても霜降り肉!をモットーにしております