戦略的設計と戦術的設計：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）を通じてそれを利用するという基本的なパターンから、パートナーシップや共有カーネルまで、チームの関係性と技術的な統合方法を合わせて記述する。

コンテキストマップはコードではなく図や文書として表現されることが多い。しかしその価値は、チーム間の「暗黙の前提」を可視化して、依存関係を明示的に管理できる点にある。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。