ドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころ

ドメイン駆動設計（DDD）とは｜ドメインを中心に据える設計思想

DDDとは、ソフトウェアが対象とする業務領域（ドメイン）の構造を、そのままコードの構造に反映させる設計アプローチです。 Eric Evansが2003年に提唱しました。技術的なレイヤ分割の手法ではなく、「何をモデリングするか」に主眼があります。

前提条件として、業務側と対話できる環境が要ります。ドメインエキスパート（業務に最も詳しい人）と会話せずに進めると、DDDは単なる命名規約の集合に変わります。例外的に、開発者自身が業務に深く精通しているケースでは対話相手を兼ねられます。

DDDが解こうとしている問題

多くの開発現場では、業務側が使う言葉とコード上の名前がずれています。営業が「契約」と呼ぶものが、コードでは Order だったり Subscription だったりする。この翻訳コストが、仕様変更のたびに誤解とバグを生みます。

DDDはこのずれを設計課題として扱います。言葉を統一し、その言葉どおりにコードを書く。 これが出発点です。

ドメインとドメインモデル

ドメインは、ソフトウェアが扱う業務領域そのものを指します。ECなら受注・在庫・配送、勤怠管理なら打刻・申請・承認といった具合です。

ドメインモデルは、その業務の中から「ソフトウェアで扱うべき概念と規則」だけを抜き出した表現を指します。業務の完全な写像ではありません。目的に対して不要な要素は、意図的に落とします。ここを取り違えて業務フローを丸ごとクラス化すると、モデルが肥大します。

ユビキタス言語

ユビキタス言語は、チーム全員（業務側・開発側の双方）が同じ意味で使う用語の集合です。会議でも仕様書でもコードでも、同じ語を使います。

実務上は用語集を1枚作るところから始まります。「解約」と「退会」を分けるのか、同義として扱うのか。この粒度の合意が、後の境界設計に効いてきます。用語集は作って終わりではなく、業務側との会話で新しい語が出るたびに更新します。

ミニFAQ：ユビキタス言語は英語で作るべきですか？

日本語の業務用語をそのまま使って構いません。重要なのは業務側と開発側で語が一致することで、言語の選択ではないためです。ただしコード上の識別子は英語になるため、用語集に「日本語の業務用語 ⇔ 英語の識別子」の対応表を持たせると、翻訳のブレを防げます。

DDDの全体像｜戦略設計と戦術設計の2層

DDDは戦略設計と戦術設計の2層に分かれます。 先に着手すべきは戦略設計です。境界を決めずに戦術パターンを入れても、置き場所の決まらないクラスが増えるだけだからです。

Microsoftのドメイン分析によるマイクロサービスのモデル化でも、境界の特定を先に行い、そのうえで戦術的DDDのパターンを各境界内に適用する順序が示されています。

クリーンアーキテクチャとの関係と棲み分け

DDDとクリーンアーキテクチャは、しばしば同時に語られますが役割が違います。DDDは「何をモデリングするか」、クリーンアーキテクチャは「依存の向きをどう制御するか」を扱います。 前者はモデリングの方法論、後者は構造の制約です。

組み合わせて使われるのは、DDDで抽出したドメインモデルが、クリーンアーキテクチャの最内層に素直に収まるためです。ただし片方だけでも成立します。

本記事はモデリング側に絞っています。4層構造・依存性逆転・層をまたぐデータの受け渡しといった構造面は、「クリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説」で扱っているため、そちらを参照してください。

戦略設計｜境界づけられたコンテキストとユビキタス言語

戦略設計の成果物は「どこで区切るか」の合意です。 具体的にはサブドメインの分類、境界づけられたコンテキストの定義、コンテキスト間の関係整理の3つを行います。

ドメインとサブドメインの分類

大きなドメインは、そのままでは扱えません。サブドメインに分割し、さらに3種類に色分けします。

この分類の実務的な価値は、設計の労力をどこに集中させるかが決まる点にあります。全領域に均等にDDDを適用しようとすると破綻します。汎用サブドメインに集約やリポジトリを丁寧に作り込むのは、たいてい投資対効果に合いません。

境界づけられたコンテキスト

境界づけられたコンテキストは、1つのユビキタス言語が一貫して通用する範囲です。同じ「商品」という語でも、販売の文脈では価格とキャンペーンを持ち、物流の文脈では寸法と重量を持ちます。これを1つのクラスに統合しようとすると、どちらの業務にも合わない巨大なモデルができます。

Martin FowlerのBounded Contextでも、モデルの統一を諦めて境界を引くことが要点として説明されています。「1つの完璧なモデルを作らない」という割り切りが、境界設計の核心です。

境界の引き方の目安を挙げます。

• 同じ語の意味が変わる箇所は、境界の候補です

• 業務の担当部署が変わる箇所は、境界と一致しやすい傾向があります

• 一緒に変更されるものは同じ境界に、別々に変更されるものは別の境界に置きます

• 迷ったら最初は粗く区切ります。統合より分割のほうが後から実施しやすいためです

コンテキストマップ

コンテキストマップは、定義した境界どうしの関係を図にしたものです。どちらが上流でどちらが下流か、モデルをそのまま受け取るのか変換層を挟むのかを明示します。

実務で効くのは、組織の力関係が設計に現れる点を可視化できることです。他部署が持つシステムのモデルを変えられないなら、変換層（腐敗防止層）を自分側に置く判断になります。この判断を暗黙にしたまま実装に入ると、相手のモデルの都合が自分のドメインモデルに侵食します。

ミニFAQ：境界づけられたコンテキストとマイクロサービスの単位は一致させるべきですか？

一致させると運用しやすいケースが多い一方、必須ではありません。1つのコンテキストを複数サービスに分ける構成も、複数コンテキストを1つのデプロイ単位にまとめる構成も成立します。まず境界を論理的に定義し、デプロイ単位は組織規模や運用体制から別途決めるのが安全です。サービス分割の判断基準は「マイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説」で整理しています。

戦術設計｜エンティティ・値オブジェクト・集約の使い分け

戦術設計は、1つの境界づけられたコンテキストの中でモデルをコードに落とすためのパターン群です。 適用範囲は境界の内側に限られます。境界をまたいで同じ集約を共有しようとすると、境界を引いた意味が失われます。

エンティティと値オブジェクト

この2つの違いは、同一性をIDで判断するか、値で判断するかです。

判断に迷ったときは「属性がすべて入れ替わっても同じものとして追跡したいか」を問います。追跡したいならエンティティです。

値オブジェクトの実務上の効き目は、不正な値がモデルに入る経路を塞げる点にあります。金額を単なる整数型で持つと、負数やまるめ誤差の検証が呼び出し側に散ります。値オブジェクトにまとめると、検証が1か所に集まります。

集約とリポジトリ

集約は、一貫性を保つ単位でまとめたエンティティと値オブジェクトのかたまりです。外部からは集約ルートと呼ばれる代表オブジェクト経由でのみ操作します。

集約の大きさは、DDDで最も判断が割れる部分です。目安を挙げます。

• 「同時に更新されないと業務ルールが壊れる」範囲だけを1つの集約に入れます

• 集約をまたぐ整合性は、即時ではなく結果整合で許容できないか検討します

• 集約が大きくなるほど、同時更新の競合が起きやすくなります

• 参照だけが目的なら、集約に含めずIDだけを保持します

リポジトリは、集約の永続化を担当します。集約1つにつきリポジトリ1つが基本形です。テーブル単位でリポジトリを作ると、集約の境界が崩れます。

ドメインサービス・ファクトリ・ドメインイベント

残る3つは補助的な位置づけです。

ドメインサービスは、特定のエンティティにも値オブジェクトにも属さない業務ルールを置く場所です。「この口座から別の口座へ振り替える」のように、複数のオブジェクトにまたがる操作が該当します。置き場所に困ったものを何でも入れる場所ではありません。ここが膨らんでいるなら、モデリングが不足しているサインです。

ファクトリは、生成手順が複雑な集約の組み立てを担当します。コンストラクタで表現しきれない場合に使います。

ドメインイベントは、業務上意味のある出来事（「注文が確定した」など）を記録し、他の処理を起動する仕組みです。境界をまたぐ連携を疎結合にする用途で使われます。

軽量DDDの落とし穴｜戦術パターンだけを取り入れた場合

軽量DDDとは、戦術設計のパターンだけを導入し、戦略設計を行っていない状態を指します。 実務ではこの状態に留まっているケースがよく見られます。

批判的に語られることが多い一方、完全な無価値ではありません。整理すると次のようになります。

問題は、得られないものが時間差で顕在化する点です。実装は整っているのに、仕様変更のたびに広範囲へ影響が及ぶ。用語が統一されていないため、業務側との会議で認識がずれ続ける。この段階になってから境界を引き直すのは、初期に引くより工数がかかります。

軽量DDDから抜け出す順序

既に軽量DDDで動いているシステムを立て直す場合、いきなり全面的な境界再設計に入る必要はありません。次の順序が現実的です。

1. 用語集を作る（着手から2〜4週間程度）。業務側と一緒に、現行コードの主要な名詞を棚卸しします。この段階で「同じ語が別物を指している」箇所が洗い出されます

2. 意味がずれている語を起点に境界候補を引く。コード全体を一度に見る必要はありません。ずれている語の周辺だけを対象にします

3. コアドメインを1つ選ぶ。全域ではなく、事業上重要で変更頻度が高い領域を1つだけ選びます

4. 選んだ領域から境界を実装に反映する。四半期単位で1コンテキストずつ進めるのが、既存システムでは無理がありません

ミニFAQ：軽量DDDはやめたほうがよいですか？

現時点で実装の整理という効果が出ているなら、急いで捨てる必要はありません。判断の分かれ目は「仕様変更のたびに想定外の箇所が壊れているか」です。壊れているなら境界の不在が原因である可能性が高く、戦略設計に着手する価値があります。壊れていないなら、そのドメインは戦略設計を必要としない程度の複雑さかもしれません。

DDDが向くプロジェクト・向かないプロジェクトの判断基準

DDDは万能ではありません。 導入判断は、ドメインの複雑さ・変更の頻度・対話相手の有無の3点で行えます。

向いているケース

• 業務ルールが複雑で、条件分岐が多い（保険の料率計算、与信判断、運賃計算など）

• 仕様が継続的に変わり、数年単位で運用する前提がある

• 業務に詳しい担当者と定期的に会話できる体制がある

• 複数チームで開発しており、担当範囲の境界を明示する必要がある

• 既存システムの用語が統一されておらず、コミュニケーションコストが実害になっている

向いていないケース

• 画面の入力内容をそのまま保存するだけのCRUD中心のシステム。業務ルールが薄い領域に集約やリポジトリを導入しても、コード量が増えるだけになりがちです

• 短期間で作って役目を終えるツールや検証用のプロトタイプ

• 業務側と話せる相手がおらず、仕様書だけが渡される体制

• チーム内にDDDの経験者がおらず、学習時間も確保できない状況

判断用のチェックリストを置きます。当てはまる数が多いほど、戦略設計まで踏み込む価値があります。

• 同じ言葉を部署によって違う意味で使っている

• 仕様変更の影響範囲が事前に読めない

• 業務ルールの置き場所が、サービス層とDB層に散らばっている

• 新メンバーが業務を理解するまでに1か月以上かかる

• 今後2年以上、機能追加を続ける計画がある

3つ以上当てはまるなら戦略設計から、1〜2個なら値オブジェクト中心の部分適用から始める、というのが現実的な線引きの一例です。この個数は公式に定められた基準ではなく、チーム体制や既存コードの状態によって前後します。

現場でのDDD導入ステップと所要期間の目安

導入は「言葉 → 境界 → コード」の順で進めます。 先にコードから入ると、軽量DDDに着地します。

以下は5〜10名程度の開発チームで、既存システムに段階的に適用する場合の目安です。チーム規模や既存コードの状態で変わります。

ステップ1：用語集の作成（2〜4週間）

業務側を交えて主要な名詞を洗い出します。会議は週1回・1時間程度を数回。ここで完璧を目指さず、意味がずれている語を見つけることを優先します。

ステップ2：サブドメインの色分け（1〜2週間）

洗い出した領域をコア・支援・汎用に分類します。この分類は事業側の判断が要るため、プロダクト責任者を巻き込みます。

ステップ3：境界づけられたコンテキストの定義（2〜4週間）

コアドメインを中心に境界を引き、コンテキストマップを描きます。この時点ではコードに手を付けません。

ステップ4：1コンテキストへの戦術設計の適用（四半期単位）

選んだ1つのコンテキストに対して、集約・値オブジェクト・リポジトリを設計します。全域へ同時展開はしません。

全体を通して、最初の1コンテキストが動き始めるまでに3〜6か月を見込むケースが見られます。新規開発ではこれより短縮できますが、既存システムの改修では既存コードとの共存期間が加わります。なおこの期間は上記の前提（5〜10名規模・既存システムへの段階適用）での目安であり、公開された統計に基づく数字ではありません。

設計の進め方を体系的に学びたい場合は、「エンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップ」と「基本設計書の書き方｜項目一覧・粒度の判断基準と詳細設計書との違い」が参考になります。

フリーランスエンジニアから見たDDD｜案件での扱われ方と単価

DDDという語そのものより、「業務を聞いて境界を設計した経験」が案件で評価されます。 募集要項にDDDと書かれていなくても、設計フェーズから入る案件では同種の能力が問われます。

まず母集団と、その限界を明示します。以下は、首都圏中心の主要フリーランスエージェント数社の公開案件ページ（週4〜5日・準委任）を2026年9月時点で確認した範囲での観測です。件数としては数十件規模を見た限りの傾向にとどまります。

この観測には次の限界があります。DDDを明記した案件数を集計した公的な統計は確認できておらず、以下は統計調査ではありません。また面談時にのみ提示される非公開案件は含まれず、確認時期や対象エージェントを変えれば傾向も変わります。数値ではなく傾向の参考として読んでください。

その範囲では、募集要項に「ドメイン駆動設計」「DDD」が明記される案件は多くありません。記載がある場合はバックエンドまたはアーキテクト寄りのポジションに偏り、Java・Kotlin・TypeScript・Goなどでの実装経験とセットで求められるケースが見られます。公開案件数が限られる領域のため、観測ベースの目安として読んでください。

該当する募集で想定されている人物像は、実務経験5年以上で、業務要件のヒアリングから設計まで一人称で進めた経験がある層です。実装のみの経験で応募できる募集は、確認した範囲では少数でした。

なお、具体的な単価レンジは職種・言語によって幅があります。バックエンド全体のレンジは「バックエンドフリーランスの単価相場｜言語別・レイヤー別レンジと動向」、単価の上げ方の体系は「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」で整理しています。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。設計フェーズから入れる案件を探す場合は、案件一覧から条件を絞り込むこともできます。

案件で設計経験を見せる書き方

スキルシートに「DDD経験あり」とだけ書いても、判断材料になりません。次の要素が入っていると、設計フェーズの経験として読み取ってもらえます。

• 対象業務の複雑さ（扱った業務ルールの種類、関係部署の数）

• 自分が決めた範囲（境界の定義まで担当したのか、既存の境界内で実装したのか）

• 業務側との関わり方（ヒアリングの頻度、用語集の整備を担当したか）

• 移行の進め方（既存システムからの切り出しを何コンテキスト分担当したか）

学習の優先順位を決める観点は「単価を上げる学習の優先順位｜案件需要から逆算する技術投資4ステップ」、設計・技術選定の役割で入る場合の役割定義は「テックリードとは？仕事内容・年収・PMやEMとの違いをエンジニア視点で解説」が参考になります。

まとめ

DDDは、業務の言葉とコードを一致させるための設計アプローチであり、その中心は戦術パターンではなく境界の設計にあります。 戦術設計だけを取り入れた軽量DDDは実装の整理には効きますが、変更に強い構造は得られません。

• DDDの目的は、エンジニアと業務側が同じ言葉で話せる状態を作ること

• 戦略設計（境界の定義）から着手し、戦術設計（コードでの表現）はその内側に適用する

• ドメインの複雑さ・変更頻度・対話相手の有無の3条件で導入可否を判断する

• 既存システムでは、用語集の作成（2〜4週間）から始め、1コンテキストずつ四半期単位で進める

• CRUD中心のシステムや短命なツールでは、値オブジェクトの部分適用に留める選択も妥当

• 案件では「DDD経験」より「業務を聞いて境界を設計した経験」が評価されやすい

次のステップとしては、担当しているシステムの主要な名詞を20個ほど書き出し、業務側と意味が一致しているかを確認するところから始められます。ずれが見つかった語が、最初の境界の候補になります。

参照した一次情報・解説は次のとおりです。

• ドメイン分析によるマイクロサービスのモデル化 - Microsoft Learn

• 戦術的DDDを使用したマイクロサービスの設計 - Microsoft Learn

• Bounded Context - Martin Fowler

• Domain Driven Design - Martin Fowler