目次を表示する

EvansとVernonで学ぶDDD

エピローグ ── EvansとVernonのどちらを選ぶか

エピローグ ── EvansとVernonのどちらを選ぶか

本書で学んだことの整理

各章の核心を以下に列挙する。

ラベル章核心
[共通]Ch.2 ユビキタス言語開発者とドメインエキスパートが同一の言語を使うことがDDDの出発点。言語とモデルは双方向に洗練し合う
[共通]Ch.3 境界づけられたコンテキストモデルの意味的な境界を引くことで、同一の用語が異なる文脈で異なる意味を持つ問題を解消する
[共通]Ch.4 Context Map複数のコンテキストがどのような関係（上流/下流、共有カーネル等）で連携するかを可視化する
[Vernon追加]Ch.5 Event Stormingドメインエキスパートと開発者が付箋を使ってイベントを洗い出し、境界を発見するワークショップ手法
[共通]Ch.6 Entity と Value Object同一性（ID）で識別するEntityと、属性値で等価性を判断するValue Objectの区別がドメインモデルの基礎
[比較]Ch.7 集約Evansは「不変条件を守るオブジェクトのクラスター」と定義し、Vernonは設計判断を4つのルールに具体化した
[Vernon追加]Ch.8 ドメインイベント「ドメイン内で起きた過去の事実」をオブジェクトとして表現する。青本にはない概念
[Vernon追加]Ch.9 CQRS と Event Sourcing書き込みと読み取りモデルの分離（CQRS）と、状態ではなくイベントの系列を永続化する手法（Event Sourcing）
[比較]Ch.10 アーキテクチャEvansはレイヤードアーキテクチャを提示し、Vernonはヘキサゴナルアーキテクチャ（ポート＆アダプター）を実践的な選択肢として示した
[実装]Ch.11 TypeScriptで全パターンを繋げる採用管理システムを通し事例に、各章の概念を一つの実装として統合した

EvansとVernonの本質的な違い（再整理）

2人の仕事の性格は根本的に異なる。

Evansが定義したのは「DDDとは何か」だ。 2003年当時、「ドメインの複雑さをソフトウェアの中心に置く」という設計思想を体系的に言語化したものは存在しなかった。ユビキタス言語、境界づけられたコンテキスト、エンティティ、値オブジェクト、集約──これらの概念は青本によって初めて名前と定義を与えられた。青本は哲学書であり語彙集だ。具体的なアーキテクチャパターンへの言及は少なく、「どう実装するか」の問いには多くを答えていない。

Vernonが具体化したのは「DDDをどう実装するか」だ。 2013年という執筆時期は重要な文脈だ。CQRS、ドメインイベント、ヘキサゴナルアーキテクチャ、Event Sourcingといったパターンの議論が成熟していた時代であり、Vernonはそれらの現代的なパターンとDDDを統合する形で赤本を書いた。集約の4ルール、ドメインイベントによる結果整合性、CQRS による読み書きの分離──赤本の内容は設計判断の基準として直接実務に接続できる。

両者は競合ではない。VernonはEvansの語彙をそのまま継承し、Evansが踏み込まなかった領域を埋めた。赤本の前提には青本があり、青本を知らずに赤本を読むことはできるが、「なぜそう設計するか」の深みは青本から来る。

「どちらを選ぶか」への回答

正直に言えば、「EvansとVernonのどちらを選ぶか」という問いの立て方自体がずれている。2人は同一のDDDという体系の異なる側面を扱っており、どちらか一方を捨てることは選択肢にならない。

より実用的な問いは「どの場面でどちらを参照するか」だ。以下に整理する。

設計場面参照すべき出典理由
境界づけられたコンテキストの設計Evansの戦略的設計コンテキストの定義と関係性の語彙はEvansが起源
集約の設計Vernonの4ルール「何をトランザクション境界に含めるか」の判断基準はVernonが具体化した
アーキテクチャの選択Vernonのヘキサゴナルアーキテクチャ2003年当時のレイヤードアーキテクチャより現代の依存性管理に適合する
ドメインイベントとCQRSVernonこの概念自体が青本にない
「なぜ設計するか」の理由Evans設計判断の根拠はEvansの概念定義に遡る

青本を読んでいなくても赤本は理解できる。 Vernonは青本の概念を赤本の中で再定義しながら説明しているため、赤本単独で読み進めることは可能だ。ただし、「集約は小さく設計する」「1トランザクション1集約」といったルールの根拠が腑に落ちるかどうかは、Evansの不変条件の定義を理解しているかどうかに依存する。実務で設計判断を説明する必要が生じたとき、「Vernonがそう言っているから」以上の根拠を示したいなら、青本を読む価値がある。

DDDを適用すべき場面・すべきでない場面

EvansもVernonも共通して指摘していることがある。DDDはどこにでも適用すべき設計手法ではないという点だ。

適用すべき場面

DDDが有効なのは、ビジネスルールが本質的に複雑なコアドメインだ。

採用管理システムで言えば、選考管理コンテキストがそれにあたる。「どのタイミングでどのステージに進めるか」「誰が評価権限を持つか」「採用枠の消費をどう管理するか」という判断は、業務の中心にある複雑なルールであり、コードの中に正確に表現する価値がある。ユビキタス言語でドメインエキスパートとの認識を揃え、集約で不変条件を保護し、ドメインイベントで整合性を保つ設計は、こうしたコアドメインにこそ意味を持つ。

Evansは「コアドメインに集中せよ」という戦略的設計の原則を提示している。システム全体のうち、競争優位の源泉となる部分は通常10〜15%程度にすぎない。残りは汎用サブドメインと支援サブドメインだ。

適用すべきでない場面

CRUDが中心のシンプルなサブドメインにDDDを適用することはアンチパターンだ。

採用管理システムの通知コンテキストを考えると、その責務はドメインイベントを受け取ってメールを送信することだ。複雑なビジネスルールは存在せず、状態遷移もない。ここに集約やユビキタス言語の整備に工数をかけることは、設計の複雑さを増やすだけで業務上の価値を生まない。

同様に、マスターデータの管理や外部サービスのラッパーとして機能する汎用サブドメインにも、DDDの戦術的パターンを適用する必然性は低い。トランザクションスクリプトやActive Recordパターンのほうが実装コストと保守性の観点で優れる場面は多い。

「DDDをシステム全体に適用する」という発想そのものがアンチパターンだ。 どこに複雑さがあるかを見極め、複雑さのある部分にだけDDDを適用する判断が求められる。

次のステップ

青本・赤本への誘導

本書を読み終えた後、原典にあたる場合の読み方を示す。

青本（Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2003） を読む場合、最初から通読する必要はない。Part IIの戦術的設計（エンティティ、値オブジェクト、集約、リポジトリ）と、Part IVの戦略的設計（境界づけられたコンテキスト、Context Map）を中心に読むことで、本書の[共通]章の背景を補完できる。

赤本（Vaughn Vernon, “Implementing Domain-Driven Design”, 2013） を読む場合、本書の[比較]章と[Vernon追加]章に対応する部分──集約の設計（Chapter 10）、ドメインイベント（Chapter 8）、アーキテクチャ（Chapter 4）──を対応づけながら読むと理解が深まる。

日本語コミュニティリソース

日本語圏でDDDの実践知を発信しているリソースとして、松岡幸一郎氏のブログと同人誌がある。実装例を交えた解説が多く、青本・赤本の概念を日本語の文脈で理解する際の補助として活用できる。DDDコミュニティjpはSlackベースのコミュニティであり、実務での疑問を議論できる場として機能している。

実務への適用のヒント

ユビキタス言語から始める。 コードを変える前に、チームとドメインエキスパートが使う言語を揃える作業から着手する。既存のコードベースにあるクラス名や変数名と、業務用語のギャップを書き出すことが最初の一歩だ。この作業だけでも、コミュニケーションコストと仕様誤解の削減に直接効果がある。

小さく始める。 一番複雑なコアドメインの集約を1つ選び、そこにだけVernonの4ルールを適用してみる。システム全体をDDDで再設計しようとすると頓挫する。「選考管理コンテキストの ScreeningProcess 集約だけ直す」という限定的なスコープから始めることが現実的だ。

「DDDを導入する」という目標を立てない。 DDDは技術スタックでも、導入すれば完了するものでもない。「このコアドメインの複雑さをコードの中に正確に表現する」という具体的な課題に対応する手段として使うものだ。手段が目的化した瞬間、設計は過剰になる。

インフォグラフィック

サマリー

章末図：本書全体のサマリー

graph TD
  Evans["Eric Evans\n青本（2003年）\n'Domain-Driven Design'"]
  Vernon["Vaughn Vernon\n赤本（2013年）\n'Implementing DDD'"]

  subgraph Common["[共通] 両者が共有する概念"]
    direction LR
    UL["ユビキタス言語\nCh.2"]
    BC["境界づけられた\nコンテキスト\nCh.3"]
    CM["Context Map\nCh.4"]
    EVO["Entity / Value Object\nCh.6"]
  end

  subgraph Compare["[比較] アプローチが異なる概念"]
    direction LR
    AGG["集約\nCh.7\nEvans: 概念定義\nVernon: 4ルール"]
    ARCH["アーキテクチャ\nCh.10\nEvans: レイヤード\nVernon: ヘキサゴナル"]
  end

  subgraph VernonOnly["[Vernon追加] 赤本が導入した概念"]
    direction LR
    ES["Event Storming\nCh.5"]
    DE["ドメインイベント\nCh.8"]
    CQRS["CQRS /\nEvent Sourcing\nCh.9"]
  end

  Evans -->|"哲学・語彙・概念定義"| Common
  Evans -->|"設計原則の基盤"| Compare
  Vernon -->|"実践知の継承"| Common
  Vernon -->|"具体的設計ルール"| Compare
  Vernon -->|"現代的パターンの統合"| VernonOnly

  Common --> Impl["Ch.11 TypeScriptで全パターンを繋げる"]
  Compare --> Impl
  VernonOnly --> Impl

  style Evans fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
  style Vernon fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
  style Common fill:#f0fdf4,stroke:#86efac
  style Compare fill:#fefce8,stroke:#fde047
  style VernonOnly fill:#fff1f2,stroke:#fca5a5
  style Impl fill:#f5f3ff,stroke:#c4b5fd

Evans（青）の貢献: DDDという体系に名前と定義を与えた。コアドメインへの集中という戦略的視点、ユビキタス言語という協働の手段、集約という不変条件の保護機構──これらの概念的な枠組みが2003年以降の設計思想の基盤になった。

Vernon（赤）の貢献: Evansの概念に設計判断の基準を与えた。集約の4ルール、ドメインイベントによる結果整合性、ヘキサゴナルアーキテクチャとの統合、CQRS と Event Sourcing──2013年時点の技術的成熟を背景に、実装可能な形でDDDを更新した。

2つの書籍は競合ではなく、10年の時間差を経た継承関係にある。どちらから読み始めてもDDDに入ることはできるが、両方を参照することで設計判断の根拠と実践の手段が揃う。