シリーズ構成（全10章）
Ch.1 プロローグ（本章） / Ch.2 戦術的DDDの全体像 / Ch.3 Value Object / Ch.4 Entity / Ch.5 集約 / Ch.6 Services と Repository / Ch.7 Domain Events / Ch.8 アンチパターン・カタログ / Ch.9 2026年のDDD論争総覧 / Ch.10 エピローグ
この記事が解決する「状態」
DDDを学び始めたエンジニアが必ずぶつかる状態がある。
・本は何冊か読んだ。概念は理解した。
・でも実装すると、レイヤーを守ることだけに必死になっている。
・Value Object を量産したら、ボイラープレートで窒息した。
・集約の境界で毎スプリント議論しているが、決着しない。
・気がつくと「DDDをやっている」こと自体が目的化している。この状態を終わりにする。
この記事は、戦術的DDD（Tactical DDD） の8つのパターン── Value Object / Entity / 集約 / Domain Service / Application Service / Repository / Factory / Domain Events ──を、実務で使い倒した体験ベースで深掘りする。単なる解説ではなく、「どのパターンが費用対効果に見合い、どのパターンが”使わない判断”を迫られるか」 を、肯定面と否定面の両方から整理する。
そして、2026年の現在、戦術的DDDは20年間で最も揺さぶられている。集約を殺せと唱える DCB（Dynamic Consistency Boundary）、垂直分割を推す Vertical Slice Architecture、LLMがコードを書く時代のドメインモデリングの意義── これらの論争を、最終章（Ch.9）で総ざらいする。
この記事で得られるもの
読み終えると、あなたは：
1. 8つの戦術的パターンを「使う／使わない」判断軸を持てる
2. パターンごとの代表的な失敗を、症状・根本原因・脱出法で識別できる
3. 2026年のDDD論争の立ち位置を地図上に配置できる
4. 自分のプロジェクトに「どの粒度でDDDを導入するか」を設計できる「DDDをやっているつもり」から、「必要な分だけDDDを使っている」状態への移行を支援する。
対象読者
対象：DDDの概念は一度学んだが、実務での適用に迷うエンジニア
レイヤードアーキテクチャやクリーンアーキテクチャを実装した経験がある方
「DDDの本を読んだが手応えがなかった」という方
難易度：★★★★☆
読了時間：約3時間
前提知識：オブジェクト指向の基礎
DDDの基本用語（境界づけられたコンテキスト、集約など）を聞いたことがある
TypeScriptの読解（コード例はすべてTypeScriptで記述）概念の初学者向けではない。「概念は知っているが、実装に落とす段階で止まっている」人向けに書いている。
姉妹記事との関係
本シリーズには姉妹記事が2本ある。
| 記事 | 焦点 | 本記事との関係 |
|---|---|---|
| EvansとVernonで学ぶDDD | 2冊の原典の比較 | 本記事は原典を前提に、実務で使い倒した体験を扱う |
| DCB（Dynamic Consistency Boundary） | 集約を超える新概念 | 本記事Ch.5・Ch.9 で概要に触れ、深掘りは姉妹記事に譲る |
Evans と Vernon の思想差を知りたい方は前者を、集約の限界を乗り越える最新の議論を追いたい方は後者を合わせて読むと立体的に理解できる。
通し事例：SaaS契約・課金管理システム
本記事全体を通じて、SaaS契約・課金管理システム を題材にする。この題材を選んだ理由は3つある。
- ビジネスルールが豊富：プラン変更、比例按分（proration）、トライアル、支払い失敗の再試行など、ドメインルールが自然に発生する
- 集約境界が議論的：Subscription・Invoice・Customer・PaymentMethod をどう切るか、正解が一意でない
- 2026年的：SaaSは2026年時点で最も普遍的なビジネスモデルの一つであり、読者の想像力を借りやすい
扱う境界づけられたコンテキストは以下の4つだ。
| コンテキスト | 責務 |
|---|---|
| 契約管理（Subscription） | 顧客のプラン契約と状態遷移を管理する |
| 課金（Billing） | 請求書生成・比例按分・支払い記録を管理する |
| 顧客（Customer） | 顧客プロフィールと組織情報を管理する |
| 通知（Notification） | ドメインイベントを受信してメール・Slack送信を行う |
本記事の焦点は 契約管理コンテキスト と 課金コンテキスト だ。この2つは密結合しやすく、戦術的DDDの題材として最も豊富な論点を含む。
graph LR
Subscription[契約管理<br/>Subscription]
Billing[課金<br/>Billing]
Customer[顧客<br/>Customer]
Notification[通知<br/>Notification]
Subscription -->|PlanChanged<br/>TrialEnded| Billing
Subscription -->|SubscriptionActivated| Notification
Billing -->|PaymentFailed| Notification
Customer -->|CustomerRegistered| Subscription本記事の構成パターン
本記事は「問題提起 → 解決パターン → 批判的検証」の流れで各章を構成する。
Ch.2 で全体像の地図を示す
↓
Ch.3〜Ch.7 で各パターンを深掘り（肯定／否定の両論を併記）
↓
Ch.8 でアンチパターンを症状・根本原因・脱出法で整理
↓
Ch.9 で2026年の論争を総覧
↓
Ch.10 で判断軸と導入戦略をまとめる各章のコード例はすべてTypeScriptで書かれており、特定のフレームワークには依存しない。
筆者の立場表明
公平を期すため、本記事を書く筆者の立場を先に明かす。
・DDDは「正しく使えば強力な武器」だと考えている。
・同時に、「多くのDDD導入プロジェクトは過剰適用で失敗している」と観察している。
・戦術的DDDの8パターンのうち、費用対効果が明確に高いのは
Value Object と Domain Events の2つだと考えている。
・集約・Repository・Service はプロジェクト文脈次第で
「使わない判断」が正解になることが多いと考えている。この立場は本記事の基調をなす。異なる立場の読者は、その差分を持ち帰って自分の判断に活用してほしい。
ここから始まる
次章では、戦術的DDDの全体像を一枚の地図に広げる。8つのパターンを「導入コスト × 得られるリターン」で配置し、どこから手をつけるべきかの優先順位を提示する。
では、始めよう。