ブログ記事
戦略的設計と戦術的設計：Vlad Khononov『ドメイン駆動設計をはじめよう』
ドメイン駆動設計（DDD）の書籍は、エリック・エヴァンスの原典から始まり多数存在するが、「どこから始めて、どう全体像を掴むか」に悩む開発者は多い。Vlad Khononov の『ドメイン駆動設計をはじめよう』（原題: Learning Domain-Driven Design）は、この問いに正面から答えることを目的として書かれた入門書だ。
1. DDDを「戦略」と「戦術」に分けて理解する
本書の構成は明確だ。DDDを「戦略的設計」と「戦術的設計」の2層に分け、それぞれを独立して理解できるように整理している。
戦略的設計はビジネスの構造をソフトウェアのアーキテクチャに反映する活動だ。どの領域が事業の競争優位を生む「コアドメイン」で、どの領域が汎用的な「支援サブドメイン」かを見極め、それに応じて開発の投資配分を決める。
戦術的設計は、コードレベルでドメインロジックを表現するパターンだ。値オブジェクト、エンティティ、集約、ドメインイベントといった構成要素を使って、ビジネスのルールをコードに落とし込む。
両者は独立していない。戦略がなければ戦術的パターンを適切に配置できず、戦術がなければ戦略を実装に落とせない。
2. コアドメインを見つけることの重要性
すべてのドメインに同じコストをかける必要はない、というのが本書の出発点の一つだ。
競合と差別化できるコアドメインには投資する。汎用的な処理（認証、メール送信、請求書発行など）は既存のサービスや外部パッケージを使う。この区別をつけずにすべてをスクラッチ実装すると、開発リソースが競争優位に貢献しない作業に費やされる。
「コアドメインとは何か」を明確にするには、ビジネス担当者との対話が必要になる。エンジニアだけで判断できない問いだ。
3. 境界づけられたコンテキストで「ユーザー」の曖昧さを解消する
「ユーザー」という言葉は、文脈によって意味が変わる。ECサイトで言えば、購入者・配送先・請求先・サポート対象、それぞれに異なる属性とルールがある。これを一つの User クラスに詰め込もうとすると、条件分岐だらけの複雑なコードが生まれる。
境界づけられたコンテキストは、この問題へのアーキテクチャレベルの解答だ。各コンテキスト内でモデルは独立して定義される。「購入コンテキスト」の Customer と「配送コンテキスト」の Customer は、同じ実体を指していても、それぞれ自分のコンテキストで意味のある属性だけを持つ。
4. コンテキストマップでシステム間の関係を可視化する
コンテキストが複数になると、それらをどう統合するかが問題になる。本書が「コンテキストマップ」として整理するのは、この統合パターンの分類だ。
上流コンテキストがモデルを公開し（Open Host Service）、下流が翻訳層（Anti-Corruption Layer）を通じてそれを利用するという基本的なパターンから、パートナーシップや共有カーネルまで、チームの関係性と技術的な統合方法を合わせて記述する。
コンテキストマップはコードではなく図や文書として表現されることが多い。しかしその価値は、チーム間の「暗黙の前提」を可視化して、依存関係を明示的に管理できる点にある。
flowchart LR
subgraph CORE["コアドメイン（差別化領域）"]
C1["購入コンテキスト\nCustomer＝購入者"]
end
subgraph SUP["支援サブドメイン"]
C2["配送コンテキスト\nCustomer＝配送先"]
C3["請求コンテキスト\nCustomer＝請求先"]
end
C1 -->|"Open Host Service\n→ Anti-Corruption Layer"| C2
C1 -->|"Open Host Service\n→ Anti-Corruption Layer"| C3
style CORE fill:#f3e5f5,stroke:#9c27b0
style SUP fill:#e8f4fd,stroke:#4a9eda
5. どんな設計の悩みに効くか
「設計をきれいにしたい気持ちはあるのに、どの部分に手間をかけ、どこは既製品で済ませていいのかの線引きができない」——本書がまず効くのはこの状況だ。コアドメインとそれ以外を見極める視点が、全機能を等価に作り込む発想から、競争優位を生む領域へ投資を寄せる発想へと切り替えてくれる。
もう一つは、「ユーザー」や「注文」といった言葉がチームで微妙に食い違い、一つのクラスが条件分岐で膨らんでいく状況だ。境界づけられたコンテキストの考え方を通すと、同じ言葉を文脈ごとに別のモデルとして分けて扱えるようになり、肥大化の起点を断てる。
6. 読むべき人と、まだ早い人
向いている人：
- モノリスが肥大化し、機能追加のたびに影響範囲が広がって読み切れなくなってきたと感じるチームの開発者
- マイクロサービスへの分割を任され、どこで境界を切ればよいかの根拠がほしいアーキテクト
- DDD の用語は耳にするが全体像が掴めておらず、原典に入る前に地図を手にしたい人
向いていない人：
- 概念の厳密な定義や理論的背景まで一冊で深く押さえたい人。本書は戦略と戦術を入口として地図化することに主眼があり、踏み込んだ理論は原典に委ねる構成だ
- 扱うドメインが単純で CRUD 中心の小規模開発をしている人。戦略的設計は事業の複雑さに投資を振り分けるための道具なので、複雑さが乏しい場面では手間が上回りやすい
7. 原典との読み分け
同じ DDD を扱う本として、エリック・エヴァンスの原典『エリック・エヴァンスのドメイン駆動設計』も DevBookPath に収録されている。両者は競合ではなく役割が違う。
原典は、ユビキタス言語やモデル駆動設計といった概念の出どころと厳密な定義を与える理論の背骨だ。扱う範囲が広く定義も厳密な分、初読の負荷は高い。対して本書は、同じ概念を現代的な語り口と架空企業のケースで組み直し、戦略から戦術までの地図をまず描いて見せる入口にあたる。
初学の段階では本書で全体像を掴み、概念の根拠を確かめたくなった時点で原典へ降りる——この順で読むと、定義の厳密さと全体像の掴みやすさを両取りできる。
8. 読んだ後に進む先
読み終えて次にどこへ進むかは、掴んだ関心によって二方向に分かれる。
概念の定義や理論的な裏付けをもっと厳密に押さえたくなったなら、エヴァンスの原典『エリック・エヴァンスのドメイン駆動設計』へ。ユビキタス言語やモデル駆動設計の根拠に触れると、本書で得た地図が「なぜそう区切るのか」の判断に変わる。一方、引いた境界を組織にどう反映するかへ関心が向いたなら、『チームトポロジー』が次の一冊になる。コンテキストとチームの単位を揃えると認知負荷が下がり、価値の流れが速くなるという接続だ。
実務での最初の一歩は、自分のシステムで文脈によって意味が変わる言葉を一つ選び（「ユーザー」「注文」など）、どのコンテキストで何を指すのかを書き出してみることだ。境界の輪郭が、机上の概念から自分のコードの話になる。
筆者の体験から
テックリード寄りの立場になってから、設計レビューで「これはドメインの構造を反映しているのか」と聞かれて言葉に詰まる場面が増えた。エヴァンスの原典にも挑んだが説明が自分のプロジェクトのどこに当てはまるのかつながらず途中で止まっていた。担当していたtoBの業務システムでモノリスが肥大化していた頃、本書に頼った。
読んでからは、コアドメインかどうかの軸で投資配分を説明できるようになった。ある案件では「顧客」という一つのクラスに、営業の与信情報、請求の支払い条件、サポートの契約プランが全部乗っていて、機能を足すたびにバグの温床になっていた。境界づけられたコンテキストの章を読んだ直後にこの状態を整理して見せると、若手メンバーの方から「請求の顧客と営業の顧客は別物として扱っていいんですね」と返ってきて、新規追加分だけでも文脈ごとに分ける方針に切り替えられた。
コアドメインを決めるにはビジネス担当者との対話が必要という主張は、受託寄りの案件では実践しづらく、結局エンジニア側の推測で線を引く場面もあった。
DevBookPath のマップで確認する
この本の前後の読書順は、DevBookPath のグラフで確認できます。
本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。
この記事を共有
この地図を共有