ddd-subdomain-classification

1 行の概要

各サブドメインをコア、支援、汎用に分類し、ビジネスを実際に差別化する領域にモデリングの労力を集中させます。

このスキルを使う場面

• ロードマップの範囲を決め、どの領域に深い設計が必要か判断するとき。
• 機能のまとまりについて、内製するか購入するかを選ぶとき。
• シニアエンジニアを各チームに割り当てるとき。
• 配管部分に過剰投資しているプロジェクトのスコープを削るとき。

このスキルを使わない場面

• サブドメイン内のモデリングに関する質問 → 戦術的パターンのスキル。
• コンテキスト境界を描くとき → ddd-bounded-context。

核となる内容

ビジネスにおける役割に基づく 3 つのカテゴリーです。

コアドメイン。 競合他社との差別化につながるビジネスの部分です。顧客が次の製品ではなく、この製品を選ぶ理由です。シニアレベルのモデリングの労力をここに注ぎます。外部委託せず、テンプレート化せず、「ライブラリを使えばいい」と片付けないでください。

支援サブドメイン。 必要で、ある程度のカスタマイズも必要ですが、会社が競争に勝つ要因ではありません。作りますが、やりすぎないようにします。目指すのは「ニーズを満たすこと」であり、「クラス最高」ではありません。

汎用サブドメイン。 コモディティです。認証、基本的な請求処理、住所検証、ファイルストレージ、キーワード検索などが該当します。購入する（Stripe、Auth0、Algolia）、ライブラリを使う、または既製のフレームワークを利用します。汎用サブドメインを独自に開発するのは、ソフトウェア開発で最もコストのかかる失敗の一つです。

判断基準。 「このサブドメインが明日なくなったら、顧客は気づいて困るだろうか。また、競合他社のほうがこれをうまくできるだろうか？」はい／はいならコア、いいえ／いいえなら汎用です。その中間は支援です。

判断のヒューリスティクス

• 「Stripe／Auth0／SaaS／フレームワークのデフォルト機能を使えるか？」と問いかけます。使えるなら汎用です。機能そのものではなく、連携を構築します。
• 「顧客が競合他社ではなく当社を選ぶとき、挙げる機能は何か？」と問いかけます。それがコアです。適切な人員を配置します。
• 大規模なロードマップレビューのたびに再分類します。サブドメインは時間とともに移行します（汎用だった機能がコアになる場合も、その逆の場合もあります）。

アンチパターン

• すべてのサブドメインをコアとして扱うこと。シニアの注意がどこにも行き渡らず、実際のコアへの投資が不足します。
• 汎用サブドメインを過剰に設計すること（認証を一から作り直す、独自のメールシステムを構築する、新しい検索エンジンを書くなど）。
• 実際のコアが「退屈に感じる」ため、あるいはチームが華やかな汎用の配管部分に取り組みたがるために、コアへの投資を怠ること。
• コアをベンダーに外部委託すること。会社は差別化の要因を失います。

関連項目

• ddd-bounded-context — 分類対象となる単位です。
• ddd-design — 設計にかける労力は、この分類に基づきます。

参考資料

• Evans, Domain-Driven Design（2003 年）、第 15 章（蒸留）。