はじめに
※他の記事は手で書いていますが、この記事に関してはClaudeの音声入力を行い、内容を変えない程度に文章を整え、Claudeからのフィードバックを書いてもらっています
↓の記事良かったです
ーーーーーーーーーーーーーーーーーーーーーーー
第二回DDDオンライン勉強会：コアドメインはなぜ生まれたのか
導入
今回の目的は、エリック・エヴァンスが『ドメイン駆動設計』（2003年）でコアドメインという考え方を示した当時の開発現場を、映像が浮かぶほど具体的に理解することでした。自分で仮説を立て、それにClaudeからフィードバックをもらう形で考えを深めました。
1. 当時、優秀な開発者の力はどこに向かっていたのか
私の考え
緊急度は高いが重要度の低い仕事が優先され、重要だが緊急でない仕事が後回しにされていた。コアドメインという考え方の登場でこれが改善され、事業が成長したのではないか。
Claudeからのフィードバック
「重要なものが後回しにされた」という結論は合っているが、原因の説明がずれている。エヴァンスによれば、優秀な開発者はフレームワークや分散処理などの技術基盤に向かった。理由は緊急だからではなく、技術的に面白く、転職しても通用するスキルになるからである。つまり向かった先は「緊急だが重要でないもの」ではなく、「緊急でも重要でもないが、面白いもの」だった。
また、「後回し」の中身は、業務知識がモデルとしてコードに表現されず、画面処理やデータの入れ物の中に散らばったことである。さらに「事業が成長した」は因果の主張であり、本書はそれを示すデータを持たない。「エヴァンスはそう主張した」と「そういう結果が出た」は区別すべきである。
2. なぜポータブルスキルばかりが重視されたのか
私の考え
業務知識とポータブルスキルの二択で、ポータブルスキルを選ぶ人が多かった。
Claudeからのフィードバック
大筋は正しいが、二点補足がある。一つ目に、これは個人の好みだけでなく、組織の評価と配置の仕組みも原因だった。技術基盤の成果は目に見えて評価しやすく、業務モデルの価値は見えにくい。二つ目に、本当は二択ではない。業務知識そのものは持ち運びにくいが、業務をモデリングする力はどの業界でも通用する。
一人ひとりは合理的に選んでいるのに、全体としては悪い結果になる。この「個人の合理と全体の合理のずれ」があったからこそ、エヴァンスは個人の心がけではなく、「コアに最も優秀な人を置け」という組織への提言として書いた。
3. なぜすべての業務を同じ力で作ってはいけないのか
私の考え
同じ力で作ると、何がビジネスのコアなのかわからなくなるから。
Claudeからのフィードバック
正しいが、理由の一部にとどまる。理由は少なくとも三つある。①開発の力は有限なので、均等に配るとコアに回る力が薄まる。②力を注いだ効果は部分ごとに違い、汎用的な部分はどれだけ作り込んでも差別化にならない。③すべてが同じ密度で書かれると、コアが埋もれて見えなくなる（これが私の仮説）。
さらに因果の向きに注意。「同じ力で作る → コアがわからなくなる」だけでなく、「コアがわからない → だから同じ力で作る」も成り立ち、両者は悪循環を作る。
4. 戦略としてのリソース配分
私の考え
限られたリソースを適切な場所に配置して最大の貢献を得る、戦略的な考え方なのだと理解した。兵法とも同じだと感じた。
Claudeからのフィードバック
その通りで、「戦略」はもともと軍事用語である。『孫子』の兵力集中やランチェスター戦略と同じく、限られた力を決定的な一点に集める原理を持つ。また戦略には「何をやらないか」を決める側面もあり、汎用的な部分を既製品で済ませる判断がこれに当たる。
ただし類推には限界もある。兵法には直接ぶつかる敵がいてゼロサムだが、ソフトウェア開発の目的は顧客への価値創造である。「集中する」原理は同じでも、「何のために集めるか」は異なる。
5. 三つの分類と、その基準
Claudeからの整理
事業の全体を「事業領域（ドメイン）」、それを分けた個々の業務を「業務領域（サブドメイン）」と呼ぶ。業務領域は、「差別化につながるか」と「複雑で既存の解決策があるか」の二つの基準で三種類に分けられる。
- 中核（コア）：差別化につながり、複雑。最も優秀な人材で深く作り込む。
- 補完（支援）：差別化にはならず単純だが、自社固有で既製品がない。自社で簡素に作る。
- 一般（汎用）：差別化にはならず、既に解決策がある。既製品を使う。
コアドメインは「サブドメインの一種」であり、両者は対立概念ではなく全体と種類の関係にある。
6. なぜ分類は時間とともに変わるのか
Claudeからの整理
二つの基準はどちらも、競合や市場との比較で決まる相対的なものである。したがって、競合が追いつけばコアは汎用になり（コモディティ化）、会社が勝負する場所を変えればコアが移り、理解が深まれば分類自体が修正される。分類は一度決めて終わりではなく、見直し続ける必要がある。
7. なぜ「分類」ではなく「蒸留」なのか
私の考え
蒸留する過程で、認識合わせがあぶり出されるからではないか。
Claudeからのフィードバック
「隠れていたものが表に出てくる」という点は、蒸留の本質を捉えている。ただし表に出てくるのは「認識合わせ」ではなく「本質（コア）」であり、認識合わせはそれを取り出すための手段（熱）に当たる。
分類との違いは四つある。①分類はすでに分かれたものを仕分けるが、蒸留は混ざり合ったものから本質を分離する。②分類は中立だが、蒸留は本質を取り出すという価値の偏りを持つ。③蒸留すると本質は少量で濃くなる。④蒸留は繰り返すほど純度が上がる。加えて、エヴァンスは副産物も役に立つとしており、汎用的な部分を捨てるわけではない。
8. 戦略的設計はなぜコミュニケーションなのか
Claudeからの整理
ソフトウェアの問題の多くは、業務の専門家と開発者の認識のずれから生まれる。ユビキタス言語、境界づけられたコンテキスト、コンテキストマップ、サブドメインの分類は、いずれもこのずれを防ぐ仕組みである。また、コンウェイの法則が示すように、システムの構造は組織のコミュニケーション構造を写す。
ただし「戦略的設計＝コミュニケーション」は言いすぎで、正確には「戦略的設計の対象は人々の認識であり、その主な手段がコミュニケーションである」。
9. その後の歴史
Claudeからの整理
2003年の出版当時、業界は戦術的パターン（エンティティやリポジトリ）に飛びつき、戦略的設計は読み飛ばされがちだった。2013年にヴォーン・ヴァーノンが実装面を補い、2014年以降はマイクロサービスの流行で「サービスの境界をどこに引くか」が問題になり、境界づけられたコンテキストが再評価された。そして生成AIが実装を担い始めた現在、人間に残る仕事として戦略的設計の重要性が改めて論じられている。
10. USPとの関係
私の考え
コアドメインはUSP（Unique Selling Proposition）と似ているのではないか。
Claudeからのフィードバック
どちらも「なぜ他ではなくこれが選ばれるのか」を問う点で共通する。ただしUSPは顧客に向けた約束（外側の価値）であり、コアドメインはその約束を実現し続ける業務（内側の価値）である。USPがあってもコアドメインが支えていなければ空手形になり、コアドメインに強みがあってもUSPとして言葉になっていなければ伝わらない。両者は表と裏の関係にある。
事業側に「顧客はなぜうちを選ぶのか」と尋ねることは、コアドメインを見つける手がかりになる。ただし立地やブランドのように、ソフトウェアでは支えられないUSPもあるため、両者が常に一致するとは限らない。
結論：コアドメインの本質
コアドメインとは、「顧客が他社ではなくこの会社を選ぶ理由を生み出している業務」であり、どこで勝つかという戦略上の判断を業務の言葉で表したものです。開発の力は限られ、力を注いだ効果は業務ごとに異なるため、この分類が「誰を配置し、どう作り、何について合意するか」を決める土台になります。
全体を通しての学び
私の考え
偶有的な困難はどんどん減っているが、本質的な複雑さはずっと保存されている。私はこれまでコミュニケーションを「話せばよいもの」「センスの問題」と軽く考えていたが、それは本質的なエンジニアリングのスキルであり、真摯に向き合って学べば身につくものだとわかった。
立場によってメンタルモデルはまったく違う。たとえば顧客にとってメールは昔からある簡単な道具だが、開発者にとってはメールサーバーやSPFの設定を含む複雑な仕組みである。「メール」という言葉が出ていればまだよいが、出ていないと齟齬はさらに起きやすく、「作ったが求めていたものと違う」ことになる。また、便利な道具は目的に合わせてブラックボックス化していくため、本来なら解消できるはずの大変さが解消できないことが起きる。だからこそDDDが大事なのだと理解した。
Claudeからのフィードバック
「偶有的／本質的」の区別はフレッド・ブルックスの「銀の弾などない」（1986年）、「複雑さは消えず移るだけ」はラリー・テスラーの「複雑さ保存の法則」が原典であり、名前を添えると説得力が増す。
メールの例は、同じ言葉でも立場によってモデルが違うことを見事に示している。さらに、多くの事業にとってメール送信は「複雑だが既に解決策がある」一般的な業務領域であり、「複雑さがある場所と価値がある場所は一致しない」ことも読み取れる。また、「言葉が出ていない状態」の指摘は核心を突いている。言葉になっていれば確かめられるが、暗黙の前提は確かめる対象にすらならない。
ブラックボックス化の部分は、因果を一段補うと明確になる。便利な道具は複雑さを内側に隠すことで便利になるが、複雑さは消えたのではなく見えない場所に移っただけである。その結果、使う側のメンタルモデルは単純になり、作る側の複雑さは残る。つまり、道具が便利になるほど、使う側と作る側のメンタルモデルの差は広がる。 生成AIも同様で、偶有的な複雑さが減るほど、残された本質的な複雑さ、つまり「何を作るべきか」を揃える仕事の比重は相対的に大きくなる。これが、AI時代にDDDの戦略的設計が重要になる理由である。