はじめに
「DDDは知っている。集約とか値オブジェクトとかリポジトリのやつでしょう」
恥ずかしながら、私は長いことこの理解で止まっていました。実装パターンの引き出しとしてDDDを覚えていて、それを使うか使わないかの判断は「なんとなく複雑そうだから」でしていたのです。
本書『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を読み終えて、その理解が入口の半分でしかなかったことがよく分かりました。本書が一貫して主張しているのは、「どう実装するか」の前に「何を作るべきか」と「なぜそれを作るのか」がある、というきわめて素朴な、しかし実務では抜け落ちがちな順序です。
この記事では、本書全体を通した内容の整理と、実務エンジニアとして読んで刺さった点をまとめます。
書籍情報
| 項目 | 内容 |
|---|---|
| 書名 | ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 |
| 原書 | Learning Domain-Driven Design |
| 著者 | Vlad Khononov（ウラド・ホノノフ） |
| 訳者 | 増田 亨、綿引 琢磨 |
| 出版社 | オライリー・ジャパン |
| 発行 | 2024年7月18日 初版第1刷 |
著者はWebマスターからチーフアーキテクトまで経験し、DDD・マイクロサービス・ソフトウェアアーキテクチャのコンサルタントとして活動している方です。
本書は日本語版の訳語が大きな特徴です。Ubiquitous Language を「同じ言葉」、Bounded Context を「区切られた文脈」と訳すなど、カタカナ語をできる限り避けています。この訳語選択自体が本書の主張と地続きになっているので、後半で対応表としてまとめました。
本書の位置づけ：エヴァンス本の代わりに読める入門書
DDDといえばエリック・エヴァンスの『ドメイン駆動設計』（通称エヴァンス本）ですが、あの本は分厚く、抽象度が高く、読み通すのに気合いが要ります。
本書はそこを補う本です。
- 全体が 16章＋付録 に整理されている
- 各章の末尾に まとめ と 演習問題 がある（回答は付録B）
- 「この技法はいつ使うか」という節が各パターンに必ず用意されている
特に最後の点が重要で、本書は「パターンのカタログ」ではなく 「判断基準のカタログ」 として書かれています。トランザクションスクリプトをいつ使うか、ドメインモデルをいつ使うか、CQRSをいつ使うか。すべてが選択の問題として提示されます。
全体構成
本書は4部構成です。
第Ⅰ部 設計の基本方針 1章〜4章 …… 何を作るのかを見極める
第Ⅱ部 実装方法の選択 5章〜9章 …… どう実装するかを選ぶ
第Ⅲ部 ドメイン駆動設計の実践 10章〜13章 …… 現実のプロジェクトに適用する
第Ⅳ部 他の方法論や設計技法との関係 14章〜16章 …… 隣接領域との接続
「戦略的設計 → 戦術的設計 → 実践 → 周辺技術」という流れになっており、章を追うごとに抽象度が下がっていく素直な構成です。
第Ⅰ部：設計の基本方針
1章 事業活動を分析する
いきなりコードの話は出てきません。事業活動の分析から始まります。
著者はDDDの講座で必ず「私たちはソフトウェアを書くのが仕事で、経営をしているわけではない。これを学ぶ必要があるのか」と聞かれるそうです。その答えは明確に「必要」です。役に立つ解決策は課題の理解から生まれるのであり、開発者にとっての課題は「どんなソフトウェアを作るか」だからです。
ここで導入される概念が2つあります。
- 事業領域（ビジネスドメイン）：企業が事業を展開する領域。宅配、コーヒー、小売など
- 業務領域（サブドメイン）：事業領域を細分化したもの
そして業務領域は3つに分類されます。この分類が本書全体の土台になります。
| 分類 | 意味 | 扱い方の方針 |
|---|---|---|
| 中核 | 競合との差別化要因。会社の強みそのもの | 自社で作る。最も投資する |
| 補完 | 必要だが差別化にはならない | 自社で作るが、簡素に |
| 一般 | どの会社も同じ。既製品がある | 買う・借りる |
ここを取り違えると、あとの設計判断がすべてずれます。一般の業務領域に凝った設計を持ち込むのは過剰設計ですし、中核の業務領域を既製品で済ませるのは競争力の放棄です。
2章 業務知識を発見する
章の冒頭に置かれた、イベントストーミングの考案者アルベルト・ブランドリーニの言葉が強烈です。要旨としては、本番環境にリリースされるのは業務エキスパートの知識ではなく、開発者の理解（あるいは誤解）である、ということです。
この章の主役は 同じ言葉（Ubiquitous Language） です。
- 開発者が業務エキスパートになる必要はない
- しかし業務エキスパートの考え方を理解し、彼らが使う用語を自分たちも使う必要がある
- 要求事項をソースコードに「翻訳」しただけのソフトウェアは、特殊ケースの漏れや将来の変更に耐えられない
「モデルとは何か」「効果的なモデルとは何か」という節も置かれており、モデルは現実の完全な複製ではなく、特定の目的のために作られた簡略化である、という立場が明示されます。
3章 事業活動の複雑さに立ち向かう
同じ言葉は「一貫して同じ意味」でなければなりません。しかし現実の組織では、部門ごとに同じ用語が別の意味で使われます。
本書のテレマーケティングの例が分かりやすいです。
- 販売促進部門にとっての「見込み客」＝ 興味を持った人の連絡先が手に入った、という単発の出来事
- 営業部門にとっての「見込み客」＝ 時間をかけて進行する営業プロセスのライフサイクル全体
営業部門の複雑なモデルを販売促進部門に持ち込めば過剰設計になり、逆にすれば不十分な設計になります。
この矛盾を解くのが 区切られた文脈（Bounded Context） です。用語の意味が通用する範囲を、明示的に境界で区切ってしまう。境界の内側では一貫性を保ち、境界をまたぐときは変換する。
業務領域と区切られた文脈の関係も丁寧に整理されています。
- 業務領域 → 課題の空間。事業側の都合で決まる
- 区切られた文脈 → 解決策の空間。設計判断として自分たちで決める
この2つを混同しないことが、本書を通じて繰り返し強調されます。
4章 区切られた文脈どうしの連係
境界を切ったら、次は境界どうしをどうつなぐかです。本書は連係方法をチーム間の協力関係で3分類しています。
緊密な協力
| 名称 | 内容 |
|---|---|
| 良きパートナー | 双方向で臨機応変に調整する。APIの変更も協力して吸収する |
| モデルの共有 | 一部のモデルを共有する。共有範囲は最小限にすべき |
利用者と供給者の関係
| 名称 | 内容 |
|---|---|
| 従属する関係 | 利用側が供給側のモデルをそのまま受け入れる |
| モデル変換装置 | 利用側が変換層を設け、外部モデルの侵入を防ぐ |
| 共用サービス | 供給側が汎用の公開インターフェースを用意する |
互いに独立
意思疎通のコストが高すぎる場合や、モデルの差が大きすぎる場合は、あえて連係せず重複を許す選択肢もある、というものです。
そして全体を俯瞰する道具として 文脈の地図（Context Map） が紹介されます。設計上の関係だけでなく、組織の力学までが可視化されるのがこの図の価値です。
第Ⅱ部：実装方法の選択
ここからようやくコードの話になります。ただし本書の姿勢は一貫していて、どの実装方法を使うかは業務ロジックの複雑さで決まる、というものです。
5章 単純な業務ロジックを実装する
トランザクションスクリプト
処理手順の中に業務ロジックを直接書くやり方です。唯一かつ最大の要件はトランザクション管理であり、成功か失敗のどちらかで終わり、中途半端な状態を残さないこと。名前の由来もここにあります。
「それほど単純な話ではない」という節があり、分散環境で暗黙にトランザクション境界が壊れる例が示されます。
アクティブレコード
データ構造がやや複雑な場合に、データベースのレコードをオブジェクトとして扱い、そこにアクセスロジックを持たせるやり方です。
いずれも「単純な業務ロジック」向けで、補完・一般の業務領域や、CRUDが中心の画面に適しています。
本書は「トランザクションスクリプトはアンチパターン」という立場を取りません。適用条件を外したときにアンチパターンになる、という書き方をしています。この現実的な姿勢は好感が持てました。
6章 複雑な業務ロジックに立ち向かう
ドメインモデルの章です。集約・値オブジェクト・ドメインイベント・ドメインサービスといったおなじみの部品が登場します。
著者はここで用語の整理をしています。エヴァンスが示した集約や値オブジェクトは「戦術的DDD」と呼ばれることがあるが、著者はファウラーの用語を使い、業務ロジックの実装方法は「ドメインモデル」であり、集約や値オブジェクトはそれを実装するための部品である、と位置づけます。
題材はヘルプデスクのサポートチケットです。優先度ごとのSLA、エスカレーション、対応時間の短縮、自動再割り当て、自動クローズ、再オープンの可否——といったルールが絡み合う様子が示され、これはCRUD画面ではないと明言されます。
7章 時間軸でモデルを作る
イベントソーシングとイベント履歴式ドメインモデルの章です。
現在の状態ではなく、状態を変えた出来事の履歴を真実の情報源として保存する。現在の状態はイベントを畳み込んで導出する、という考え方です。
利点・欠点が正直に並べられているのが良いところで、「よくある質問」として性能・データ削除・他のやり方ではだめか、といった実務的な懸念にも回答が用意されています。
8章 技術方式
アーキテクチャの章です。3つが比較されます。
| 技術方式 | 適した業務ロジック実装 |
|---|---|
| レイヤードアーキテクチャ | トランザクションスクリプト、アクティブレコード |
| ポートとアダプター | ドメインモデル |
| コマンド・クエリ責任分離（CQRS） | 複数のモデルを目的別に持ちたい場合 |
ポートとアダプターの節では依存関係逆転の原則が丁寧に説明され、CQRSの節では読み取りモデルの投影方法や、投影の遅延にどう向き合うかという課題まで踏み込みます。
「スコープ」という節があるのも印象的でした。技術方式の選択はシステム全体ではなく区切られた文脈ごとに行う、という当たり前だけれど見落としやすい話です。
9章 通信
境界をまたぐ通信の実装パターンです。
- モデルの変換：状態なし／状態ありの2種類
- 送信箱（Outbox）：DB更新とメッセージ発行の原子性を担保する
- サーガ：長時間にわたる処理を、イベントとコマンドの連鎖で進める
- プロセスマネージャー：分岐や判断を伴う処理の流れを明示的に管理する
サーガとプロセスマネージャーの違いを明確に線引きしている解説は貴重だと思います。
第Ⅲ部：ドメイン駆動設計の実践
10章 設計の経験則
第Ⅰ部・第Ⅱ部の判断基準が、意思決定の流れとして整理し直されます。
- 区切られた文脈の切り方
- 業務ロジックの実装方法の選び方
- 技術方式の選び方
- テストの基本方針（ピラミッド形／ダイヤモンド形／逆ピラミッド形）
テストの形が業務ロジックの実装方法と対応づけられている点が面白く、ドメインモデルならピラミッド形、アクティブレコードならダイヤモンド形、といった具合に、設計判断とテスト戦略が接続されます。
11章 設計を進化させる
本書で個人的に最も価値を感じた章です。
事業活動は変化するという前提に立ち、業務領域の分類が変わったときに設計をどう追随させるかを扱います。
中核 → 一般 （競合が追いつき、既製品が登場した）
一般 → 中核 （既製品の枠を超えて差別化要因になった）
補完 → 一般
補完 → 中核
中核 → 補完
一般 → 補完
そのうえで、実装方法の移行手順が具体的に示されます。
- トランザクションスクリプト → アクティブレコード
- アクティブレコード → ドメインモデル
- ドメインモデル → イベント履歴式ドメインモデル
特に最後の移行では、既存データから過去のイベント履歴をどう復元するか、復元できない部分を「移行イベント」としてどう表現するか、という現実的な話まで書かれています。ここまで書いてくれる本はなかなかありません。
組織変更に伴う連係方法の移行（良きパートナー → 利用者と供給者 → 互いに独立）も扱われ、コンウェイの法則的な視点が設計判断に組み込まれています。
12章 イベントストーミング
ローテクなモデリング手法として、付箋とホワイトボードを使うワークショップの進め方が10ステップで解説されます。
1. 発散的に探索する … とにかくイベントを出す
2. 時系列に並べる
3. 問題点を洗い出す
4. 転換イベントを見つける … 流れが大きく変わる点
5. コマンドを見つける
6. ポリシーを定義する
7. 読み取りモデルを見つける
8. 外部システムを追加する
9. 集約を見つける
10. 区切られた文脈に分割する
面白いのは、この10ステップがそのまま本書の設計概念の発見手順になっていることです。イベント→コマンド→ポリシー→読み取りモデル→集約→区切られた文脈、という順で、本書のここまでの概念が順番に立ち上がってきます。
ファシリテーションのコツやリモート開催時の注意点も書かれており、実際にやる人向けの実用的な内容です。
13章 現実世界のドメイン駆動設計
既存システム（いわゆるレガシー）へのDDD適用です。
- 戦略的な分析：事業活動を理解し、既存システムの構造を調べる
- 設計改善：基本方針の改善、実装方法の改善、同じ言葉を育てる
- DDDを売り込む：組織にどう導入するか
最後の節がとても現実的で、「DDDを導入しましょう」と正面から提案するのではなく、非公式に取り入れるやり方が推奨されています。業務エキスパートの言葉をそのままコードに使う、設計判断の理由を言語化する、といった小さな実践から始めるアプローチです。
第Ⅳ部：他の方法論や設計技法との関係
14章 マイクロサービス
「マイクロサービスの境界＝区切られた文脈」という単純な等式を、本書は明確に否定します。
- 区切られた文脈はモデルの境界であり、マイクロサービスの境界の最大値
- 集約は分割の最小値
- 業務領域が実用的な落としどころになりやすい
そして「メソッド単位のサービスが完璧なマイクロサービスか？」という挑発的な問いを立て、深いモジュール（公開インターフェースは小さく、内部の機能は豊かに）という考え方を導入します。サービスを小さくすればするほど良いわけではない、という主張です。
15章 イベント駆動型アーキテクチャ
イベント駆動を安易に採用したときの失敗例として 「分散した大きな泥団子」 が紹介されます。
結合の分類が有用でした。
| 結合の種類 | 内容 |
|---|---|
| 時間的な結合 | 実行順序に依存している |
| 機能的な結合 | 同じ業務ロジックが複数箇所に散っている |
| 実装の結合 | 内部構造の変更が外部に波及する |
イベントの種類（イベント通知／イベント伝達状態転送／ドメインイベント）と、どの種類をどの境界で使うべきかの経験則も整理されています。内部向けと公開向けでイベントを分ける、という指針は実務ですぐ効きます。
16章 データメッシュ
業務系データモデルと分析系データモデルの違い（事実テーブル・特性テーブル）から入り、データウェアハウス／データレイクの課題を経て、データメッシュに至ります。
データメッシュの原則が、DDDの語彙で説明されるのが本章の面白いところです。
- データを業務の視点で分割する（＝業務領域による分割）
- データをプロダクトと考える
- 自律性を高める
- エコシステムを構築する
分析基盤の話がDDDと地続きになる、という視点は新鮮でした。
訳語対応表
本書を読むうえで、訳語の対応を把握しておくと理解が早いです。英語の資料と行き来する際にも役立つので、まとめておきます。
| 原語 | 本書の訳語 |
|---|---|
| Business Domain | 事業領域 |
| Subdomain | 業務領域 |
| Core / Supporting / Generic | 中核 / 補完 / 一般 |
| Ubiquitous Language | 同じ言葉 |
| Bounded Context | 区切られた文脈 |
| Context Map | 文脈の地図 |
| Partnership | 良きパートナー |
| Shared Kernel | モデルの共有 |
| Conformist | 従属する関係 |
| Anticorruption Layer | モデル変換装置 |
| Open-Host Service | 共用サービス |
| Separate Ways | 互いに独立 |
| Domain Expert | 業務エキスパート |
| Event-Sourced Domain Model | イベント履歴式ドメインモデル |
| Ports and Adapters | ポートとアダプター |
| CQRS | コマンド・クエリ責任分離 |
| Outbox | 送信箱 |
| Pivotal Event | 転換イベント |
| Fact Table / Dimension Table | 事実テーブル / 特性テーブル |
「腐敗防止層」ではなく「モデル変換装置」、「顧客・供給者」ではなく「利用者と供給者の関係」。訳語がそのまま役割の説明になっているので、初学者に説明するときに圧倒的に楽です。
読んで刺さった点
1. 実装パターンの選択に、事業側の根拠が与えられる
これまで「複雑そうだからドメインモデルにしよう」と曖昧に判断していた部分に、中核／補完／一般という事業側の軸が接続されます。設計レビューで「なぜこの実装方法なのか」を説明できるようになるのが大きいです。
2. 「いつ使うか」が必ず書いてある
トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式ドメインモデル、レイヤード、ポートとアダプター、CQRS、イベントストーミング。すべてに「いつ使うか」の節があります。パターン本ではなく判断基準の本、という設計思想が徹底しています。
3. 設計は進化する前提で書かれている
11章の存在が本書を実務書にしています。最初から正しい設計を引き当てる必要はなく、事業の変化に応じて移行していけばよい。そしてその移行手順まで書いてある。
4. マイクロサービスの境界に明確な指針が示される
「区切られた文脈が最大値、集約が最小値」という表現は、そのまま設計議論の共通言語として使えます。
こんな人におすすめ
- DDDという言葉は知っているが、実装パターンの知識で止まっている方
- エヴァンス本で挫折した、あるいは積んでいる方
- マイクロサービスの分割粒度で毎回議論が発散している方
- レガシーシステムの改善方針を立てたい方
- 設計判断の根拠をチームで言語化したい方
逆に、集約や値オブジェクトの実装コードをひたすら読みたい方には物足りないかもしれません。本書のコード例は概念を伝えるための最小限にとどまっています。
読み方の提案
一気に通読するより、以下の順で読むのが実務的だと感じました。
- 1〜4章（第Ⅰ部）を丁寧に読む。ここが全体の土台です
- 10章（設計の経験則）で判断基準の全体像をつかむ
- 5〜9章（第Ⅱ部）を、いま自分が担当しているシステムに当てはめながら読む
- 11章（設計を進化させる）で移行の道筋を確認する
- 12〜16章は必要に応じて
各章末の演習問題は飛ばさずにやると理解が定着します。回答は付録Bにあります。
まとめ
本書の結びでは、課題への合意がないまま解決方針を語っても、解決方針への合意がないまま実現手段を語っても意味がない、という趣旨のゴールドラット・アシュラグの言葉が引かれています。
- 課題 ＝ 事業領域と業務領域の理解
- 解決方針 ＝ 区切られた文脈と同じ言葉
- 実現手段 ＝ 業務ロジックの実装方法と技術方式
この3段構えが本書の骨格そのものです。私たちエンジニアはつい実現手段から考えてしまいますが、その手前に2段階あることを、本書は16章かけて繰り返し示してくれます。
DDDを「難しくて敷居の高いもの」と感じていた方にこそ、最初の1冊として勧めたい本でした。