ドメイン駆動設計（Domain-Driven Design、DDD）は、業務の知識をモデルにし、そのモデルをコードの中心に置く設計手法です。提唱者はエリック・エヴァンス（Eric Evans）で、2003年の著書『Domain-Driven Design: Tackling Complexity in the Heart of Software』で体系化しました。この記事では、DDDの意味とドメインという語の指す範囲、ユビキタス言語・エンティティ・値オブジェクト・集約などの用語、モデリングの進め方、メリットとデメリット、採用しない方がよい条件、2026年時点で読む書籍の順序までを、原典と公式資料にあたって整理します。
まとめ：DDDの要点と、採用可否を分ける3つの条件
DDDの核は、業務で使う言葉とコードのモデルを一致させ、その一致をチームで保ち続けることです。エンティティや集約といったパターンは、その一致を支える道具です。パターンの導入自体を目的にせず、業務の理解とモデルの検証につなげます。
採用の判断は3つの条件で切り分けます。業務ルールが複雑で条件分岐が多いこと。そのルールが今後も何度も変わること。業務の専門家と継続的に話せる体制があること。3つを満たすなら、DDDは採用を検討する価値があります。投資の回収は開発規模やチームの習熟度にも左右されるため、そこは別に見積もります。業務ルールが入力チェック程度ならCRUD実装が先。専門家と話せないなら、まず業務知識を確かめられる体制づくりからです。
進め方の基本は、業務を洗い出してサブドメインに分け、競争優位に直結するコアドメインを見極め、その内側をエンティティや集約で組むことです。境界とコードは一度で決まらず、何度か往復します。以下、用語・構成要素・進め方・メリットとデメリット・学習ルートの順に掘り下げます。
ドメイン駆動設計（DDD）とは｜業務の知識をモデルにしてコードの中心に置く設計手法
DDDは、データベースのテーブル設計から入るのではなく、業務の関心事を先に理解してモデル化し、それをそのままコードへ落とす設計手法です。業務で「注文を確定する」と呼ぶ操作が、コード上でも同じ語で表現されていれば、仕様変更を伝えるときの翻訳が要らなくなります。
マーティン・ファウラーは2020年4月22日の解説「DomainDrivenDesign」で、DDDを「業務領域のプロセスとルールを深く理解したドメインモデルのプログラミングを開発の中心に据える手法」と説明し、込み入ったロジックを抱える複雑なドメインに特に向くとしています。
DDDの読み方と略・提唱者｜Domain-Driven Designとエリック・エヴァンス
DDDは Domain-Driven Design の頭字語で、読みは「ディー・ディー・ディー」です。提唱者のエリック・エヴァンスは2003年8月に原著をAddison-Wesleyから刊行し、邦訳『エリック・エヴァンスのドメイン駆動設計』は翔泳社から2011年4月8日に出ました。「ドメイン駆動開発」という表記も見かけますが、Design を「開発」と意訳した表記揺れで、指すものは同じです。書籍や公式訳では「ドメイン駆動設計」が定着しています。
エヴァンスは原著のパターン定義を要約した「Domain-Driven Design Reference」（現行PDFの著作権表示は2015年）を、クリエイティブ・コモンズ表示（CC BY 4.0）で無償配布しています。用語の定義を確かめたいときは、原著より先にこちらを開くと速く済みます。
DDDでいうドメインとは｜業務領域のことで、ネットワークのドメインとは別物
DDDの「ドメイン」は、システムが対象とする業務領域を指します。会計、在庫、与信、配車といった、その事業が扱う問題の範囲です。URLやDNSで使うドメイン名とは無関係です。「ドメイン設計」という言い方でDDDの話をしている場合も、指しているのは業務領域のモデリングで、ここを取り違えると議論が噛み合いません。
業務領域について蓄えた知識をドメイン知識と呼びます。DDDが求めるのは、手順書の作業内容だけでなく「なぜその条件で承認が要るのか」という判断の根拠まで噛み砕いた業務知識です。この根拠が開発側へ移っていなければ、仕様変更のたびに専門家への確認が発生し続けます。
コアドメイン・支援サブドメイン・汎用サブドメイン｜設計工数を集める場所の見分け方
ドメインは一枚岩ではなく、役割で3種類に分けます。コアドメインは競争優位に直結する中核業務、支援サブドメインはコアを補助する自社固有の業務、汎用サブドメインは認証や請求書発行のようにどの企業でも共通の業務です。物流会社なら配車ルールがコア、勤怠管理は汎用にあたります。
この分類は工数配分に使います。汎用は既製のSaaSやライブラリへ寄せ、支援は業務ルールの複雑さに応じた実装にし、モデリングへの投資はコアドメインを優先する。見分けの問いは「この業務がうまいと競合に勝てるか」の一つで足ります。
モデル駆動設計（Model-Driven Design）｜DDDの中のパターン名とMDAとの違い
「モデル駆動設計」は、エヴァンスがDDDの中で定義したパターンの名前です。DDD Reference は、ソフトウェアの一部をドメインモデルに「極めて忠実に」対応させて対応関係を明白にし、ソフトウェアとして自然に実装できるようモデルの側も見直して、分析と実装の両方に使える単一のモデルを求める、と定義しています。分析用の図と実装用のコードを別々に作って「変換」する発想とは逆で、コードがモデルの表現そのものになります。
名前が似ているOMGのMDA（Model Driven Architecture）は、プラットフォーム非依存のモデルと実装技術に依存するモデルを分け、変換によって実装につなぐアプローチです。コード生成はその実現手段の一つで、DDDとは着眼点が異なり、併用も可能です。DDDではモデルは図に限らず、会話・コード・テストのすべてで表現されるものとして扱います。
戦略的設計と戦術的設計｜境界の設計と実装パターンの往復
DDDは二層構造です。戦略的設計は「どこに境界を引き、どのモデルをどの範囲で通用させるか」を扱います。戦術的設計は「その境界の内側をどう組むか」を扱い、エンティティ・値オブジェクト・集約などのパターンがここに入ります。
戦術パターンは、どこが境界でどこに投資するかを意識して選びます。境界を切らずに集約やリポジトリだけを並べても、巨大な単一モデルが整理されるわけではありません。一方で、両者は一方通行の工程ではなく往復します。後述のDDD Crewも、MVPを急ぐ場合や、業務が複雑でコードでモデルを作らないと構成を考えられない場合には、先にコードを書く進め方を挙げています。
ユビキタス言語｜業務とコードで同じ語彙を使い続けるための運用
ユビキタス言語は、業務の専門家と開発者が共通で使う語彙です。単なる用語集ではなく、コードのクラス名・メソッド名にそのまま現れる点が要になります。会議で「与信枠を凍結する」と呼ぶ操作が、コードで freezeCreditLimit() になっていれば翻訳のずれは生まれません。updateStatus2() のような技術都合の名前になった時点で、モデルは業務から離れ始めます。
ファウラーの解説「UbiquitousLanguage」（2006年10月31日）は、この言語はソフトウェアのドメインモデルに基づく厳密なものであるべきで、専門家との会話で使うこと自体がモデルの検証になり、理解が深まるにつれて言語もモデルも育てていくものだと整理しています。運用の勘所は、語彙を決めた瞬間ではなく変わったときの追随です。業務側の呼び名が変わったら、モデル上の意味の変化も確認し、コード・テスト・用語集の更新を同じ変更作業として管理します。用語集はSSOT（信頼できる唯一の情報源）として一箇所に置き、複数のExcelへ散らばらせないことが前提です。
ユビキタス言語は、境界づけられたコンテキスト（後述）の内側でだけ通用します。販売部門の「商品」と物流部門の「商品」が別の意味を持つのは自然なことで、全社で1つの辞書に統一しようとすると、かえってどの部門の言葉にも合わなくなります。
ドメインモデルの構成要素｜エンティティ・値オブジェクト・集約・リポジトリ・ドメインサービス
ドメインモデルは、業務の概念とルールを表現したオブジェクトの集まりで、属性だけでなくルールを自分で守る振る舞いを持たせます。この発想は、オブジェクト指向のカプセル化を業務の単位まで押し広げたものと考えると掴みやすくなります。
エンティティと値オブジェクト｜同一性で見分けるか、値で見分けるか
エンティティは識別子で同一性が決まるオブジェクトです。注文番号12345の注文は、金額や明細が変わっても同じ注文であり続けます。値オブジェクトは値そのもので同一性が決まり、1,000円という金額はどの1,000円でも等価です。
判断基準は「変化を追跡する必要があるか」の一つで足ります。追跡が要るならエンティティ、要らないなら値オブジェクトです。値オブジェクトは不変にし、生成時に検証を通します。たとえば非負の販売価格を表す値オブジェクトなら負数を拒否し、複数通貨を扱うモデルなら通貨コードも保持します。この検証をコンストラクタへ置けば、不正な値がドメイン層へ入り込む経路が塞がります。
集約と集約ルート｜Vernonの4つの設計ルールと整合性境界
集約は、1つの単位として整合性を保つオブジェクトのかたまりです。ファウラーの「DDD_Aggregate」（2013年4月23日）が書くとおり、外部からの参照は集約ルートだけに向け、ルートが集約全体の整合性を保証します。注文集約なら、明細の追加や削除は必ず注文エンティティ経由で行い、合計金額の再計算も注文自身が担います。
集約の大きさについては、ヴォーン・ヴァーノンが2011年の論文「Effective Aggregate Design」で4つのルールを示しています。
- 真の不変条件（常に同時に成り立つべき業務ルール）だけを1つの整合性境界に入れる
- 集約は小さく設計する
- 他の集約はオブジェクトではなく識別子（ID）で参照する
- 集約の境界をまたぐ更新は結果整合性で行う
実務では2つ目と4つ目が効きます。原則として1トランザクションで更新する集約を1つに絞り、集約間では結果整合性を検討します。ただしヴァーノン自身も、規則を破ってよい理由として、画面で複数件をまとめて作る利便性、メッセージングなど結果整合を実装する仕組みが無い場合、2フェーズコミットのグローバルトランザクションが方針で必須の場合、クエリ性能の4つを挙げています。結果整合にするかは、業務が許す遅れから決めます。集約を大きく取ると同時更新の競合が増え、ロック待ちが慢性化します。関連や多重度を図で詰める段階では、クラス図における集約とコンポジションの違いの整理がそのまま使えます。
リポジトリ・ファクトリ・ドメインサービス｜責務の置き場を決める基準
リポジトリは集約の保存と取り出しを担い、ドメイン層からはコレクションのように見せます。保存先がRDBかKVSかはドメイン層に知らせません。ファクトリは生成が複雑なオブジェクトの組み立てを引き受けます。ドメインサービスは、特定のエンティティにも値オブジェクトにも属さないルール（複数の集約をまたぐ判定など）の置き場です。
避けたいのはドメインサービスの乱用です。迷ったらサービスへ、を繰り返すと、エンティティが属性の入れ物に退化します。まずエンティティか値オブジェクトへ置けないかを検討し、どちらにも収まらない場合の逃がし先としてドメインサービスを使います。
業務ルールをエンティティに置くコード例｜TypeScriptによる数量上限と与信枠の検証
「ルールを自分で守る」を最小のコードで示します。注文エンティティが、確定後の明細追加・同一商品の合計100点の上限・与信枠超過の3つを自分のメソッドの中で判定します。金額は整数円で扱う前提で、単価と与信枠の不正値も弾きます。呼び出し側は判定を書きません。Node.js 26.5.0の型除去機能で実行し、tsc --strict の型検査も通しています。
// 業務ルールを注文エンティティ自身に持たせる例（値オブジェクトは省略）
class Order {
private lines: { sku: string; qty: number; unitPrice: number }[] = [];
private confirmed = false;
readonly id: string;
private readonly creditLimit: number;
constructor(id: string, creditLimit: number) {
if (!Number.isSafeInteger(creditLimit) || creditLimit < 0) throw new Error("与信枠は0以上の整数円です");
this.id = id;
this.creditLimit = creditLimit;
}
addLine(sku: string, qty: number, unitPrice: number): void {
if (this.confirmed) throw new Error("確定済みの注文には明細を追加できません");
if (!Number.isSafeInteger(unitPrice) || unitPrice < 0) throw new Error("単価は0以上の整数円です");
const current = this.lines.filter((l) => l.sku === sku).reduce((sum, l) => sum + l.qty, 0);
if (!Number.isInteger(qty) || qty < 1 || current + qty > 100) throw new Error("同一商品は合計1〜100点までです");
this.lines.push({ sku, qty, unitPrice });
}
total(): number {
return this.lines.reduce((sum, l) => sum + l.qty * l.unitPrice, 0);
}
confirm(): void {
if (this.total() > this.creditLimit) throw new Error("与信枠を超えるため確定できません");
this.confirmed = true;
}
}
const order = new Order("A-001", 50000);
order.addLine("BOOK-01", 3, 4000);
order.confirm();
console.log(order.total());
try {
order.addLine("BOOK-02", 1, 3000);
} catch (e) {
console.log((e as Error).message);
}
const many = new Order("A-003", 10000000);
many.addLine("PEN-01", 100, 100);
try {
many.addLine("PEN-01", 1, 100);
} catch (e) {
console.log((e as Error).message);
}
const big = new Order("A-002", 50000);
big.addLine("PC-01", 1, 80000);
try {
big.confirm();
} catch (e) {
console.log((e as Error).message);
}実行結果は次の4行です。3行目は、同じ商品を100点追加したあとに1点足そうとして拒否された結果です。
12000
確定済みの注文には明細を追加できません
同一商品は合計1〜100点までです
与信枠を超えるため確定できません同じルールを複数のコントローラーやサービスへ分散して書くと、注文を作る経路の追加時に判定が重複したり漏れたりします。エンティティに置けば、どの経路から呼んでもルールは1箇所です。値オブジェクト（金額）から集約・リポジトリまで既存コードを段階的に置き換える手順は、DDDの実装手順（値オブジェクトから集約までのTypeScript実例）で扱っています。
境界づけられたコンテキストとレイヤ構成｜モデルの適用範囲と依存方向の設計
境界づけられたコンテキストとコンテキストマップ｜モデルが通用する範囲の切り方
境界づけられたコンテキスト（Bounded Context）は、あるモデルが通用する範囲を明示的に区切ったものです。ファウラーは「BoundedContext」（2014年1月15日）で、これをDDDの中心的なパターンと位置づけ、大きなモデルを複数のコンテキストに分けて関係を明示する方法だと説明しています。同じ「商品」でも、販売コンテキストでは価格とキャンペーンを持ち、物流コンテキストでは寸法と重量を持ちます。1つの商品クラスへ無理に統合すると、どちらの業務にも合わない巨大クラスができあがります。
コンテキスト同士の関係はコンテキストマップとして図にします。上流と下流を明示し、外部の都合が自分のドメインへ漏れる箇所には腐敗防止層（Anti-Corruption Layer）を置いて変換します。外部SaaSのデータ構造をそのままドメイン層へ流し込まないための堤防です。
コンテキストの分割はサービスの分割と混同されがちですが、別の判断です。1つのデプロイ単位の中に複数のコンテキストを置くモジュラモノリスでも成立します。プロセスまで分けるかどうかは、マイクロサービスの向き不向きの判断チェックリストと突き合わせて決めてください。
レイヤ構成と依存の向き｜ドメイン層を他の層に依存させないディレクトリ構成
レイヤ構成では、依存の向きを「外側から内側へ」に固定します。Microsoft Learn の「Design a DDD-oriented microservice」は、注文サービスをアプリケーション層・ドメイン層・インフラ層の3つのプロジェクトに分け、ドメイン層は他のどの層にも依存させない（.NETの標準ライブラリだけに依存する）構成を示しています。ディレクトリにすると、最小形は次のとおりです。
ordering/
application/ ユースケースの調整（業務ルールは書かない）
domain/ エンティティ・値オブジェクト・集約・リポジトリのインタフェース
infrastructure/ リポジトリの実装・DBアクセス・外部APIクライアントインフラ層がドメイン層のインタフェースを実装する形は依存性逆転の原則（DIP）そのものです。この依存の向きを同心円で描いたのがクリーンアーキテクチャで、オニオンアーキテクチャやヘキサゴナルアーキテクチャも、層の名前と数は違っても狙いは同じです。アプリケーション層が厚くなり業務ルールを書き始めたら、ドメイン層は再び空洞になります。
DDDの進め方｜ddd-crewの8ステップとEventStormingによるモデリング手順
DDDには決まった開発工程がありません。そこで、コミュニティのDDD Crewが初学者向けに公開している「DDD Starter Modelling Process」を手順の土台にすると、どこから手を付けるかで迷いません。8つのステップは次のとおりです。
- Understand：事業モデル・利用者のニーズ・短中長期の目標を揃える
- Discover：業務を目に見える形で、関係者と一緒に洗い出す
- Decompose：業務を疎結合なサブドメインに分ける
- Strategize：差別化に効くコアドメインを見極める
- Connect：サブドメインをつなぎ、業務の端から端までのユースケースを通す
- Organise：コンテキストの境界に合わせて自律したチームを編成する
- Define：境界づけられたコンテキストごとの役割と責務を定義する
- Code：ドメインモデルをコードにする
同リポジトリは、これがベストプラクティスとして標準化すべき一直線の手順ではないと明記しており、2〜6を何度か回してから7へ進む、7と8を並行する、といった行き来を前提にしています。一覧ではCodeが8番目ですが、コードを書き始める時期を固定するものではありません。先行する活動には、業務の発見、チーム編成、コンテキストの責務の定義も含まれます。
2番目の Discover では、アルベルト・ブランドリーニが2013年に考案したEventStormingがよく使われます。「注文が確定した」「在庫が引き当てられた」のような業務上の出来事（ドメインイベント）を過去形で付箋に書き、時系列に並べてから、出来事を起こすコマンドと関係者を足していく手法です。並んだ付箋の名詞と動詞がユビキタス言語の候補になり、付箋のかたまりが切れる場所がコンテキストの境界の候補になります。業務側の合意形成が足りない段階なら、先に要件定義の進め方へ戻る方が近道です。
EC受注で見るDDDの組み立て方｜注文集約から在庫引き当てまで
EC受注を題材に、ここまでの用語を1つの流れに並べます。コンテキストは受注・在庫・決済・配送の4つに分け、それぞれが独立したモデルを持ち、連携はイベントで行います。差別化に効くのは在庫引き当てや配送ルートの計算で、決済は外部サービスに任せる汎用サブドメインです。受注コンテキストの中心は、前述のコード例の注文集約です。
注文が確定したら、受注コンテキストは「注文確定」イベントを発行します。在庫コンテキストがこれを受け取って引き当てを実行し、失敗したら「引き当て失敗」イベントを返して、受注側が注文を保留へ戻します。注文と在庫を別トランザクションで更新できるのは、この例が引き当ての遅れと失敗後の保留を業務として許容しているからです。注文確定と在庫確保の同時成立が必須なら、業務フローや整合性境界から見直しが要ります。決済との連携では、同じイベントが再送されても二重課金にならないよう、注文IDを冪等キーとして扱います。イベントの記録そのものを状態の正とする設計に進む場合はイベントソーシング、読み取り用のモデルを分ける場合はCQRSが次の選択肢になります。
DDDのメリットとデメリット｜効く条件と、採用しない方がよい場面
DDDのメリット｜変更箇所の局所化とDBに依存しない単体テスト
うまく回ったときの効き所は2つです。1つは、業務ルールがドメイン層の一箇所に集まるため、仕様変更の影響範囲が読めるようになること。前章のコード例なら、与信のルールが変わっても直すのは confirm() だけです。もう1つは、ドメイン層がDBや外部APIに依存しないため、それらを起動せずに単体テストを回せることです。
DDDのデメリットと採用しない条件｜過剰設計になる4つのケース
デメリットは、初期のモデリング工数と学習期間が確実に増えることです。ドメインの専門家の時間も継続的に取られます。この費用が回収できないプロジェクトでは、DDDは採用しない方が結果が良くなります。
- 画面とテーブルがほぼ1対1で、業務ルールが入力チェック程度しかない管理画面
- 短期で廃棄する予定で、複雑な業務ルールがなく、モデリング費用の回収を見込めないキャンペーンサイトや検証用の社内ツール
- 業務の専門家に定期的に時間をもらえない体制（仕様が資料からしか読めない）
- チームにモデリング経験者が一人もおらず、学習に充てる期間も確保できない場合
単純な業務や短期運用では費用対効果が乏しくなり、専門家や学習時間を確保できない体制ではモデルの妥当性を検証しにくくなります。判断に迷ったら、必要になるまで作らないYAGNI原則を先に当ててください。基幹業務のように複雑なルールを長く抱えるシステムでは、どこまでをDDDで作りどこを既製品に任せるかの線引きが費用を左右します。issohでは基幹システム開発の要件整理の段階から、この線引きを含めて支援しています。
軽量DDDとモデル貧血症｜戦術パターンだけ導入して失敗する構図
ここで避けたい失敗は、業務の理解や境界の検討をせず、エンティティ・値オブジェクト・リポジトリという形だけを導入することです。俗に軽量DDDと呼ばれます。境界を切っていないので巨大な単一モデルのままで、そこへディレクトリ構成とクラス名の規約だけが増えていきます。実装コストは上がったのに変更のしやすさは改善しない、という最悪の組み合わせです。
これとは区別して点検したいのが、ファウラーが2003年11月25日に「AnemicDomainModel」として指摘したアンチパターン、モデル貧血症です。ドメインオブジェクトがゲッターとセッターだけを持ち、ルールはすべてサービスクラスに書かれた状態で、ファウラーは見た目がオブジェクト指向なだけの手続き型の設計だと批判しています。ドメイン層のクラスがゲッターとセッターで埋まっている、サービスクラスが数百行に膨らんでいる、用語集とコードの語彙が食い違っている。これらが見られたら、業務ルールの配置、サービスの責務、言葉の対応を個別に点検します。モデル間の意味の衝突が見つかった場合は、コンテキストの境界も見直します。
DDDの学習ルート｜書籍と一次資料の役割分担と読む順序【2026年時点】
エヴァンスの原著が難しく感じられる場合は、入門書で用語と具体例を押さえてから読むことを勧めます。2026年時点で日本語で読める主要書籍は役割がはっきり分かれており、順序を守ると理解が積み上がります。
| 書名 | 著者 | 出版社 | 発売日 | 役割 |
|---|---|---|---|---|
| ドメイン駆動設計入門 | 成瀬允宣 | 翔泳社 | 2020年2月13日 | 戦術パターンの入門 |
| ドメイン駆動設計をはじめよう | Vlad Khononov | オライリー・ジャパン | 2024年7月20日 | 戦略的設計の入門 |
| 実践ドメイン駆動設計 | ヴォーン・ヴァーノン | 翔泳社 | 2015年3月16日 | 実装の型 |
| エリック・エヴァンスのドメイン駆動設計 | エリック・エヴァンス | 翔泳社 | 2011年4月8日 | 原典・思想 |
最初の1冊は『ドメイン駆動設計をはじめよう』（原著 Learning Domain-Driven Design・2021年、訳：増田亨・綿引琢磨、408ページ、3,960円、ISBN 978-4-8144-0073-7）を推します。戦略的設計から先に説明し、サブドメインの分類を事業戦略と結びつける構成なので、順序を間違えにくいからです。コードから入りたい人は『ドメイン駆動設計入門』を先にしても構いませんが、値オブジェクトやリポジトリといった戦術パターンが中心なので、境界の話は後から補う必要があります。
集約の設計やリポジトリの実装を書く段階では『実践ドメイン駆動設計』が参照先になります。エヴァンスの原典は、各パターンが解こうとする問題と判断理由をまとめて確認できる本で、他の本で語彙を得てから読むと腑に落ちます。用語の定義は無償の Domain-Driven Design Reference で引けます。
書籍と並行して、小さな題材で手を動かしてください。既存システムの1コンテキストだけをDDDで作り直す、あるいはVertical Slice Architectureのような機能単位の構成と比べてみると、レイヤ分割が何を買っているのかが具体的に見えてきます。
よくある質問
DDDとは何の略ですか？
Domain-Driven Design（ドメイン駆動設計）の略で、読みは「ディー・ディー・ディー」です。業務領域（ドメイン）の知識をモデルにし、コードの中心に据える設計手法です。医療のペースメーカーの動作モードなど別分野にも同じ略語がありますが、ソフトウェア設計の文脈ではこの意味です。
ドメイン駆動設計の提唱者は誰ですか？
エリック・エヴァンス（Eric Evans）です。2003年にAddison-Wesleyから刊行した『Domain-Driven Design: Tackling Complexity in the Heart of Software』で体系化し、邦訳は2011年4月8日に翔泳社から出ました。
ドメイン駆動設計とドメイン駆動開発は違うものですか？
同じものを指します。Design を「設計」と訳すか「開発」と訳すかの表記揺れです。名前の似た「モデル駆動設計」はDDDの中のパターン名です。MDD（モデル駆動開発）はモデルを中心に進める開発の総称、MDAはOMGが定めたモデルの分離・変換の枠組みで、どちらもDDDとは別の考え方です。
ドメイン駆動設計とマイクロサービスは同じものですか？
別の概念です。DDDはモデルの境界を決める設計手法、マイクロサービスはデプロイ単位を分ける実行構成です。境界づけられたコンテキストがサービス分割の指針に使われるため一緒に語られますが、1つのアプリケーションの中でもDDDは実践できます。
ドメイン駆動設計の書籍は何から読めばよいですか？
『ドメイン駆動設計をはじめよう』（オライリー・ジャパン・2024年）で全体像を掴み、実装段階で『実践ドメイン駆動設計』、最後にエヴァンスの原典、の順が挫折しにくい経路です。コードから入りたいなら『ドメイン駆動設計入門』（翔泳社・2020年）を最初に置きます。
