ドメイン駆動設計（DDD）とは？意味・基本用語・実装と採用判断をわかりやすく解説

ドメイン駆動設計（Domain-Driven Design、DDD）は、業務そのものをソフトウェアの中心に据える設計手法です。エリック・エヴァンスが2003年の原著で体系化し、邦訳『エリック・エヴァンスのドメイン駆動設計』（翔泳社・2011年4月8日）で日本に広まりました。この記事では、DDDの意味と読み方、ドメイン・ユビキタス言語・エンティティ・値オブジェクト・集約といった基本用語、レイヤ構成、EC受注を題材にした組み立て方までを順に整理します。あわせて、DDDを採用しない方がよい条件と、2026年時点で読むべき書籍の順序も示します。

まとめ：DDDの要点と、採用可否を分ける3つの条件

DDDの核は一つです。業務で使う言葉とコードのモデルを一致させ、その一致をチームで保ち続けること。エンティティや集約といったパターンは、その一致を壊さないための手段にすぎません。パターンから入ると失敗します。

採用の判断は次の3条件で切り分けられます。第一に、業務ルールが複雑で条件分岐が多いこと。第二に、そのルールが今後も何度も変わること。第三に、業務の専門家と継続的に話せる体制があること。3つとも満たすならDDDは投資に見合います。1つでも欠けるなら、素直なCRUD実装の方が速く安く仕上がります。

DDDは全システムへ一律に敷くものではありません。競争優位に直結するコアドメインへ集中投下する考え方です。以下では用語・実装・具体例・採用判断・学習ルートの順に掘り下げます。

ドメイン駆動設計（DDD）とは｜業務の言葉をコードのモデルへ一致させる設計思想

DDDは、データベース設計から入るのではなく、業務の関心事を先に理解してモデル化し、それをそのままコードへ落とす設計思想です。業務の「注文が確定する」という出来事が、コード上でも同じ語で表現されていれば、仕様変更の伝達コストが下がります。特定の言語やフレームワークには縛られません。JavaでもC#でもGoでも実践できます。

うまく回ったときの効き所は2つです。業務ルールがドメイン層の一箇所に集まるため、仕様変更の影響範囲が読めるようになること。もう1つは、ドメイン層がDBや外部APIに依存しないため、それらを起動せずにユニットテストを回せることです。逆に、初期のモデリング工数と学習期間は確実に増えます。この差引をどう見るかが、次の章以降の判断材料になります。

DDDの読み方と略｜Domain-Driven Designの意味、「ドメイン駆動開発」との呼び分け

DDDは Domain-Driven Design の頭字語で、日本語では「ドメイン駆動設計」と訳します。読みは「ディー・ディー・ディー」。「ドメイン駆動開発」という表記も見かけますが、原語の Design を「開発」と意訳した揺れであり、指すものは同じです。

頭字語のDDDには別分野の同名語もあります。設計文脈での「DDD」はほぼ例外なく Domain-Driven Design を指すと考えて差し支えありません。

DDDでいうドメインとは｜業務領域のことで、ネットワークのドメインとは別物

DDDの「ドメイン」は、システムが対象とする業務領域を指します。会計、在庫、与信、配車といった、その事業が扱う問題の範囲です。URLやDNSで使うドメイン名とは無関係で、ここを取り違えると議論全体が噛み合わなくなります。「ドメイン設計」という言い方でDDDの話をしている場合も、指しているのは業務領域のモデリングです。

この業務領域について蓄えた知識をドメイン知識と呼びます。業務知識とほぼ同義ですが、DDDが指すのは「モデルとして表現できる粒度まで噛み砕いた業務知識」の方です。手順書に書かれた作業内容ではなく、「なぜその条件で承認が要るのか」という判断の根拠まで含む。この根拠が開発側へ移っていなければ、モデルは業務の写しにならず、仕様変更のたびに専門家への確認が発生し続けます。

ドメインは一枚岩ではなく、役割で3種類に分けます。コアドメインは競争優位に直結する中核業務、支援サブドメインはコアを補助する固有業務、汎用サブドメインは認証や通知のようにどの企業でも共通の業務です。物流会社なら配車ルールがコア、勤怠管理は汎用にあたります。汎用領域は既製のSaaSへ寄せ、自社の設計工数はコアへ集める。見分けの問いは「この業務がうまいと競合に勝てるか」の一つで足ります。

戦略的設計と戦術的設計｜先に境界、後にパターンという順序

DDDは二層構造です。戦略的設計は「どこに境界を引き、どのモデルをどの範囲で通用させるか」を扱います。戦術的設計は「その境界の内側をどう組むか」を扱います。

実務でつまずくのは、この順序を逆にしたときです。集約やリポジトリだけを導入しても、境界を切らずに一枚岩のモデルへ詰め込めば効果は出ません。戦略が先、戦術が後。この順序が守れているかどうかが、後述する失敗パターンの分かれ目になります。

ユビキタス言語｜業務とコードで同じ語彙を使い続けるための実務

ユビキタス言語は、業務の専門家と開発者が共通で使う語彙です。単なる用語集ではなく、コードのクラス名・メソッド名にそのまま現れる点が要になります。会議で「与信枠を凍結する」と呼ぶ操作が、コードで freezeCreditLimit() になっていれば翻訳ロスは生まれません。ここが updateStatus2() のような技術都合の名前になった時点で、モデルは業務から離れ始めます。

運用の勘所は、語彙を決めた瞬間ではなく、変わったときの追随です。業務側の呼び名が変わったら、コードのリネームまで同じスプリントで済ませる。用語集ドキュメントはSSOT（信頼できる唯一の情報源）として一箇所へ置き、複数のExcelへ散らばらせないことが前提になります。語彙の洗い出しにはEventStormingがよく使われ、業務イベントを時系列に貼り出してから名詞と動詞を拾う進め方が定着しました。

ドメインモデルの構成要素｜エンティティ・値オブジェクト・集約・リポジトリ

ドメインモデルは、業務の概念とルールを表現したオブジェクトの集まりです。属性だけを持つデータ構造ではなく、ルールを自分で守る振る舞いを持たせます。この「データとルールを同じ場所に閉じ込める」発想は、オブジェクト指向のカプセル化をドメインの単位まで押し広げたものと考えると掴みやすくなります。

エンティティと値オブジェクト｜同一性で見分けるか、値で見分けるか

エンティティは識別子で同一性が決まるオブジェクトです。注文番号12345の注文は、金額や明細が変わっても同じ注文であり続けます。値オブジェクトは値そのもので同一性が決まります。1,000円という金額は、どの1,000円でも等価です。

判断基準は一つで足ります。「変化を追跡する必要があるか」。追跡が要るならエンティティ、要らないなら値オブジェクトです。値オブジェクトは不変にし、生成時にバリデーションを通します。金額なら負値を弾き、通貨コードを必須にする。この検証をコンストラクタへ置けば、不正な値がドメイン層へ入り込む経路が塞がります。

集約と集約ルート｜整合性の境界を小さく保つ

集約は、まとめて整合性を保つ必要があるオブジェクトのかたまりです。外部からは集約ルート（代表となるエンティティ）だけを参照させ、内部のオブジェクトへ直接触らせません。注文集約なら、注文明細の追加や削除は必ず注文エンティティ経由で行い、合計金額の再計算を注文自身が担います。

集約は小さく保つことが原則です。1トランザクションで更新する集約は1つに絞り、複数集約にまたがる整合はドメインイベント経由の結果整合へ寄せます。集約を大きく取ると、同時更新の競合が増えてロック待ちが慢性化する。オブジェクト間の関連や多重度を図で詰める段階では、クラス図における集約とコンポジションの違いの整理がそのまま使えます。

リポジトリ・ファクトリ・ドメインサービス｜責務の置き場を決める

リポジトリは集約の永続化を担い、ドメイン層からはコレクションのように見せます。実装がRDBかKVSかはドメイン層に知らせません。ファクトリは生成が複雑なオブジェクトの組み立てを引き受けます。ドメインサービスは、特定のエンティティにも値オブジェクトにも属さないルール（複数集約をまたぐ判定など）の置き場です。

ここで避けたいのは、ドメインサービスの乱用です。迷ったらサービスへ、を繰り返すとエンティティが属性の入れ物に退化します。いわゆるモデル貧血症の入り口がここです。まずエンティティか値オブジェクトへ置けないかを検討し、どちらにも収まらない場合の逃がし先としてドメインサービスを使います。

境界づけられたコンテキストとレイヤ構成｜モデルの適用範囲と依存方向の設計

境界づけられたコンテキストとコンテキストマップ｜モデルが通用する範囲の切り方

境界づけられたコンテキストは、あるモデルが通用する範囲を明示的に区切ったものです。同じ「商品」でも、販売コンテキストでは価格とキャンペーンを持ち、物流コンテキストでは寸法と重量を持ちます。無理に1つの商品クラスへ統合すると、どちらの業務にも合わない巨大クラスができあがります。

コンテキスト同士の関係は、コンテキストマップとして図にします。上流と下流を明示し、外部の都合が自ドメインへ漏れる箇所には腐敗防止層（Anti-Corruption Layer）を置いて変換します。外部SaaSのデータ構造をそのままドメイン層へ流し込まないための堤防です。

コンテキストの分割はサービス分割と混同されがちですが、別の判断です。境界を切ることとプロセスを分けることは独立しており、1つのデプロイ単位の中に複数コンテキストを置く構成でも成立します。分散させる判断はマイクロサービスの向き不向きの条件表と突き合わせて決めてください。

レイヤ構成と依存の向き｜ドメイン層をDBとフレームワークから独立させる設計

実装のレイヤ構成では、依存の向きを「外側から内側へ」に固定します。ドメイン層はDBにもフレームワークにも依存せず、インフラ層がドメイン層のインタフェースを実装する形を取る。この依存性逆転を軸にした構成がクリーンアーキテクチャの4層構造であり、オニオンアーキテクチャやヘキサゴナルも名前と層数が違うだけで狙いは同じです。

もう一点、アプリケーション層はユースケースの調整役に徹し、業務ルールを書かないこと。ここが厚くなると、ドメイン層は再び空洞になります。

EC受注で見るDDDの組み立て方｜注文集約から在庫引き当てまで

EC受注を題材にすると、抽象的なパターンが具体化します。まずコンテキストを分けます。受注、在庫、決済、配送の4つです。それぞれ独立したモデルを持ち、連携はイベントで行います。

受注コンテキストの中心は注文集約です。注文エンティティが集約ルートとなり、注文明細を内部に抱えます。「1回の注文で同一商品を100点まで」「合計金額が与信枠を超えたら確定できない」といった業務ルールは、注文エンティティのメソッド内で判定します。呼び出し側が判定を書かないことが、ルールの散逸を防ぐ唯一の方法です。

注文が確定したら、受注コンテキストは「注文確定」イベントを発行します。在庫コンテキストがこれを受け取り、引き当てを実行する。引き当てに失敗したら「引き当て失敗」イベントを返し、受注側が注文を保留へ戻します。決済コンテキストとの連携では、同じイベントが再送されても二重課金にならないよう、注文IDを冪等キーとして扱います。返品時は在庫を戻す補償処理をイベントで表現し、元の引き当てを取り消すのではなく打ち消す取引を追加する形にしてください。

DDDを採用しない方がよい場面｜過剰設計になる条件を先に言い切る

DDDを勧める記事は多いのですが、実務で効くのは「入れない判断」を先に持っておくことです。次の条件に当てはまるなら、DDDは採用しない方が結果が良くなります。

• 画面とテーブルがほぼ1対1で、業務ルールが入力チェック程度しかない管理画面
• 運用期間が1年未満と決まっているキャンペーンサイトや検証用の社内ツール
• 業務の専門家に定期的に時間をもらえない体制（仕様が資料からしか読めない）
• チームにモデリング経験者が一人もおらず、学習に充てる期間も確保できない場合

いずれもコストの回収前にプロジェクトが終わる構図です。DDDの投資は、システムを何年も改定し続ける前提でようやく釣り合います。判断に迷ったら、必要になるまで作らないYAGNI原則を先に当ててください。それでも足りないと感じた場合にだけ、DDDを検討すれば十分です。

軽量DDDの落とし穴｜戦術パターンだけ導入して失敗する構図

最も多い失敗は、戦略的設計を飛ばしてエンティティ・値オブジェクト・リポジトリだけを導入する形です。俗に軽量DDDと呼ばれます。境界を切っていないので巨大な単一モデルのままで、そこへディレクトリ構成とクラス名の規約だけが増えていく。実装コストは上がったのに変更容易性は改善しない、という最悪の組み合わせです。

兆候ははっきり出ます。ドメイン層のクラスがゲッターとセッターだけで埋まっている、サービスクラスが数百行に膨らんでいる、用語集とコードの語彙が食い違っている。どれか一つでも当てはまったら、パターンを足すのではなく、いったん境界の設計へ戻ります。業務側の合意形成が足りていないなら、要件定義の進め方まで戻る方が近道になります。

DDDの学習ルート｜3冊の役割分担と読む順序【2026年時点】

DDDは書籍から入るのが結局は速い分野です。ただし、いきなりエヴァンス本を開くと挫折します。2026年時点で日本語で読める主要3冊は役割がはっきり分かれており、順序を守ると理解が積み上がります。

最初の1冊は『ドメイン駆動設計をはじめよう』（原著 Learning Domain-Driven Design・2021年、訳：増田亨、綿引琢磨、408ページ、3,960円、ISBN 978-4-8144-0073-7）を推します。戦略的設計から先に説明し、事業戦略との結びつきを軸に据える構成なので、順序を間違えにくいことが理由です。

2冊目は『実践ドメイン駆動設計』。集約の設計原則やリポジトリの実装が具体的で、コードを書く段階の参照先になります。エヴァンスの原著『エリック・エヴァンスのドメイン駆動設計』は3冊目に回してください。2003年の原著（邦訳2011年）だけあって記述は抽象的ですが、「なぜそう設計するのか」の根拠はここにしかありません。最初に読むと概念の海で溺れ、最後に読むと腑に落ちる。原著が2003年に書かれた事情もあり、後発2冊で得た語彙を持ってから開く方が読み進められます。

書籍と並行して、小さな題材で手を動かしてください。既存システムの1コンテキストだけをDDDで作り直す、あるいはVertical Slice Architectureのような機能単位の構成と比べてみると、レイヤ分割が何を買っているのかが具体的に見えてきます。

よくある質問

DDDとは何の略ですか？

Domain-Driven Design（ドメイン駆動設計）の略です。読みは「ディー・ディー・ディー」。業務領域（ドメイン）を中心に据えてソフトウェアを設計する手法を指します。

ドメイン駆動設計とドメイン駆動開発は違うものですか？

同じものを指します。原語の Domain-Driven Design を「設計」と訳すか「開発」と訳すかの表記揺れで、書籍や公式訳では「ドメイン駆動設計」が定着しています。

ドメイン駆動設計とマイクロサービスは同じものですか？

別の概念です。DDDはモデルの境界を決める設計手法、マイクロサービスはデプロイ単位を分ける実行構成です。境界づけられたコンテキストがサービス分割の指針として使われるため併記されやすいだけで、1つのアプリケーションの中でDDDを実践することもできます。

小規模なプロジェクトでもDDDを導入すべきですか？

業務ルールが入力チェック程度なら不要です。判断軸は規模ではなく、ルールの複雑さと改定頻度、そして業務の専門家と話せる体制の有無です。小規模でも与信計算や料金体系のような複雑なルールを抱えるなら、その部分にだけDDDを効かせる選択があります。

DDDの学習は何から始めればよいですか？

『ドメイン駆動設計をはじめよう』（オライリー・ジャパン・2024年7月20日）から入り、実装段階で『実践ドメイン駆動設計』、根拠を確認したくなった段階でエヴァンスの原典、の順が挫折しにくい経路です。並行して、既存システムの1コンテキストを題材に手を動かしてください。

関連記事

• クリーンアーキテクチャとは？4層構造・SOLID原則・依存性逆転を実装目線で解説
• オニオンアーキテクチャとは？4層構成と依存性逆転をクリーン・レイヤードとの違いから解説
• マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理
• カプセル化とは？オブジェクト指向の基本とJava実装をわかりやすく解説
• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説