DDDの原点：Eric Evans『ドメイン駆動設計』が変えた設計の考え方

ドメイン駆動設計（DDD）は2003年に Eric Evans の著書から始まった。20年以上が経過した今、DDDの用語はマイクロサービス設計やクリーンアーキテクチャの文脈でも頻繁に登場する。『エリック・エヴァンスのドメイン駆動設計』は原典として今も読まれ続けているが、分厚く難解な書籍として知られ、全体像を掴むまでに時間がかかる。

1. DDDが解こうとした問題

Evans がDDDで解こうとした問題の本質は「複雑さ」だ。

ビジネスロジックが複雑であるとき、その複雑さをコードで正確に表現するために何が必要か——この問いへの答えがDDDの出発点だ。複雑さはデータベース設計やUI実装の問題ではなく、ビジネスのドメイン（問題領域）そのものにある。

技術的な実装の問題を解くことより、ビジネスのルールと構造をコードとして正確にモデル化することを優先する——この優先順位の転換が、DDDの根幹にある考え方だ。

2. ユビキタス言語：開発者とビジネス担当者が共通の言語を持つ

本書の最初の柱がユビキタス言語（Ubiquitous Language）だ。

開発チームとビジネス担当者が同じ言葉を使う。コードの中の変数名・クラス名・メソッド名が、ビジネスの会話で使われる用語と一致している。このことで、仕様書とコードの間の翻訳コストが下がり、要件の誤解が減る。

ユビキタス言語は一度決めたら終わりではなく、ドメインの理解が深まるにつれて進化する。モデルと言語は同時に洗練される。

3. 境界づけられたコンテキストで「意味の一貫性」を守る

大きなシステムに単一のモデルを適用しようとすると、同じ言葉が異なる意味を持つ問題が生まれる。「顧客」という概念が、販売部門と配送部門と請求部門で異なる属性を持つことは珍しくない。

境界づけられたコンテキスト（Bounded Context）は、モデルが一貫した意味を持つ境界を明示的に定義する。各コンテキスト内では、そのコンテキストに固有のモデルが支配する。コンテキスト間の関係は「コンテキストマップ」として可視化する。

flowchart LR
    subgraph SC["販売コンテキスト"]
        C1["顧客\n（名前・購入履歴）"]
    end
    subgraph DC["配送コンテキスト"]
        C2["顧客\n（住所・連絡先）"]
    end
    subgraph BC["請求コンテキスト"]
        C3["顧客\n（支払い方法・請求先）"]
    end
    SC -- "コンテキストマップ" --> DC
    DC -- "コンテキストマップ" --> BC
    style SC fill:#e8f4fd,stroke:#4a9eda
    style DC fill:#e8f8e8,stroke:#4caf50
    style BC fill:#fff8e1,stroke:#f5a623

マイクロサービスとBounded Contextの対応関係は現代の設計論でも重要なテーマで、Evans の提唱がマイクロサービス設計の土台になっている面がある。

4. 集約：整合性の境界を設計する

戦術的設計の中でも特に影響力が大きいのが集約（Aggregate）の概念だ。

集約は「不変条件（ビジネスルール）をまとめて管理する単位」だ。集約のルートエンティティを通じてのみ内部の変更を行うことで、整合性が崩れる経路を限定できる。

集約の境界を小さく保つことが重要で、大きすぎる集約はパフォーマンスと整合性の両面で問題を起こしやすい。何を一つの集約として扱い、何を別の集約として分けるかは、ドメインのビジネスルールの理解に基づく判断だ。

5. この本が解決できる具体的な状況

「コードはレビューを通るが、半年後に誰も手を出せなくなる」「ビジネス側と開発側で会話のすれ違いが絶えない」「データベーステーブルを中心に設計してきたが、ビジネスルールが複雑になるとどこに何を書くか迷う」——こういった問題の根本原因を、本書は「ドメインモデルの不在」として診断する。

大規模システムの設計に初めて関わり始めたエンジニアや、「マイクロサービスの境界をどこで引くか」で迷っているアーキテクトに、設計判断の軸を与える。

6. 向いている人・向いていない人

向いている人：

• 設計経験が3年以上あり、「複雑なビジネスロジックの整理」に悩んでいる
• マイクロサービスのサービス境界を設計する必要がある
• オブジェクト指向の実装はできるが、「どこにビジネスロジックを置くべきか」の原則がない

向いていない人：

• プログラミング経験が浅い人（前提となる設計経験がないと概念が抽象的すぎる）
• 「まず動くものを作る」フェーズのスタートアップ開発（DDD はある程度の複雑さを前提とした投資対効果で判断する）
• 特定言語・フレームワークでのすぐに使える実装パターンを求めている人

7. 読み終えた後のステップ

原典で「オブジェクトでドメインを表現する」考え方を掴んだら、次はその前提を相対化してみるのも一つの道だ。『データ指向プログラミング』（Yehonathan Sharvit）は、コードとデータを分離し、不変な値・汎用的な構造（マップ・リスト）としてデータを扱うパラダイムを提示する。ドメインモデルをオブジェクトで表現する手法を学んだ後にこの本に触れると、「コードとデータを一体化させない」という対照的な発想が、DDD で組んだ設計の前提そのものを見直すきっかけになる。

筆者の体験から

前職の受託開発でtoBの業務システムを担当していた頃、業務ルールが複雑になるたびにサービスクラスへif分岐を積み増していた。テーブル設計から実装に入る癖が抜けず、ロジックをどこに書くかその場しのぎで決めていたのが実情だった。最初に本書を開いたときは抽象的な記述に阻まれて読み切れなかった。別の複雑な機能を任されてから読み直すと、書かれている内容が自分の困りごとと重なって見えてきた。

読み直して以降に根づいたのはユビキタス言語と集約だ。レビューで「この名前は業務側の言い方と違う」と指摘するようになってから、仕様確認の往復が明らかに減った。集約を「不変条件をまとめて守る単位」と捉え、ルート経由でしか内部を変更しないというルールをチームの実装規約に入れてからは、ロジックの置き場所に迷う場面が減った。

うまくいかなかったこともある。要件が固まりきらない初期段階の案件で集約やコンテキストの境界をきっちり設計したら、その後の仕様変更で境界ごと引き直す羽目になった。読めば実装まで一直線というより、複雑さに一度直面してから効く本だと思う。

DevBookPath のマップで確認する

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

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

📖 Amazon で購入する

---

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