超要約
ビジネスの複雑さをコードで正しく映すための“言葉合わせ”と“責任の境界線”が DDD の核心だよ。
「DDD って概念だけは聞いたことあるけど、何が嬉しいの?」――そんなキミに贈る、一気読みで分かる 戦術的×戦略的 DDD 超入門。難解な理論をできるだけ日本語のままシュッと落とし込みます。
- 1. 🧭 DDD の主な目的
- 2. 🗣️ ユビキタス言語 (Ubiquitous Language)
- 3. 🧱 ドメインモデル vs. データモデル
- 4. 🧍 エンティティ (Entity)
- 4.1. Clean Architecture との違い
- 5. 📦 値オブジェクト (Value Object)
- 6. 🗃️ リポジトリ (Repository)
- 7. 🏗️ 集約 (Aggregate)
- 8. 🩸 ドメイン貧血症 (Anemic Domain Model)
- 9. 🌐 境界づけられたコンテキスト (Bounded Context)
- 10. ⚠️ 軽量 DDD (アンチパターン) に注意
- 11. 📌 まとめ & 次のステップ
- 12. FAQ
🧭 DDD の主な目的
ビジネスの複雑さをコードに正しく反映 すること。
- ドメイン (= ビジネス領域) へ集中した設計を促す
- フレームワークやデータストアに引っ張られない“純粋ロジック”の温存
🚩 ― 実装とビジネスの言語ギャップがバグも技術的負債も生むから。
🗣️ ユビキタス言語 (Ubiquitous Language)
定義:プロジェクト全員が 同じ単語で同じ概念を指す ための共通語彙。
✔️ どうして重要?
- コード・テスト・会話・設計図が一枚の辞書を共有し、誤解を根本から削減
- 仕様変更時も「言葉」を追うだけで影響範囲が見える
💡 Tip — 名前付けに悩んだらドメインエキスパートに 1 分インタビューしよう。「この概念、業務ではなんて呼びます?」
🧱 ドメインモデル vs. データモデル
観点 | ドメインモデル | データモデル |
---|---|---|
目的 | 業務ルール・振る舞いの表現 | 永続化効率・正規化 |
関心 | 振る舞い & 不変条件 | ストレージ & パフォーマンス |
主な形 | エンティティ / 値オブジェクト / サービス | テーブル / ドキュメント / インデックス |
設計者 | ドメインエキスパート + 開発者 | DBA / インフラエンジニア |

SQL の JOIN 地獄をドメイン層に持ち込むと、途端に “データモデル内乱” が起きるから注意だよ
🧍 エンティティ (Entity)
識別子 (ID) を持ち、ライフサイクルと同一性を扱うオブジェクト。
- 振る舞いと状態を抱え込む「現場責任者」的存在
Clean Architecture との違い
観点 | DDD のエンティティ | Clean Architecture のエンティティ |
---|---|---|
抽象度 | ドメイン固有で具体的 | システム全体に共通する最内核ロジックでさらに抽象的 |
目的 | 業務ルール遂行 | アプリのビジネスルール保持 |
📦 値オブジェクト (Value Object)
不変 かつ ID を持たない。
- 値が同じならオブジェクト同士も等しい (equals 比較)
final class Money
{
public function __construct(
private readonly int $amount,
private readonly string $currency
) {}
public function add(self $other): self
{
if ($this->currency !== $other->currency) {
throw new CurrencyMismatchException();
}
return new self($this->amount + $other->amount, $this->currency);
}
}

コピーしても壊れないからテストがラクちんだよ〜。
🗃️ リポジトリ (Repository)
役割:集約を “保存する/取り出す” 手段を抽象化し、ユースケース と インフラ の仲介役になる。
interface OrderRepository
{
public function byId(OrderId $id): ?Order;
public function save(Order $order): void;
}
- ドメイン層には インフラ詳細を漏らさない
- 操作対象は 集約ルート限定 ― これ大事!
🏗️ 集約 (Aggregate)
不変条件 (Invariant) の塊 —— 整合性は常に内側で完結。
- 外部は ルート (Aggregate Root) のみ参照可能
- ルート越しでしか内部要素を操作できない
- 1 集約 = 1 トランザクション

要するに一家に一戸口方式だね〜。
🩸 ドメイン貧血症 (Anemic Domain Model)
振る舞いがデータ構造から剥がれ落ち、サービス層に散在した状態。
典型的副作用:ビジネスルールが if 文地獄 で再実装され、変更コストが跳ね上がる。
💉 処方箋 — 振る舞いをエンティティ/値オブジェクトへ戻そう。
🌐 境界づけられたコンテキスト (Bounded Context)
日本語訳案:「モデル整合領域」
- 同じ単語 (“在庫”) でも 経理 と 配送 では意味がズレる
- コンテキストを分けて 言葉とルールの整合性 を保とう
⚠️ 軽量 DDD (アンチパターン) に注意
- 戦術パターンだけ (Entity, Repository など) を形だけ導入
- ビジネス理解が浅いままなので、モデルが業務とズレて「DDD っぽいけど役に立たない」設計に
🎯 対策:
- ドメインエキスパートと対話 → ユビキタス言語をコード化 → 戦術パターンで形にする、の順番を守る
📌 まとめ & 次のステップ
- 言葉合わせ → モデル化 → 実装 の順番が DDD の黄金パス
- 小さなコンテキストから試して、成功体験 をチームに輸血しよう
- 次は イベントストーミング で要件を可視化してみるとさらに理解が深まるかも?

ぼくもイベントストームで付箋ペタペタ貼りたい〜!
FAQ
-
そもそも「DDD」って、何のためにやるの?
-
「ビジネスの複雑さをちゃんとコードに落とす」ため。
フレームワークやDBに引きずられず、本当に必要な“業務ロジック”を守るための考え方。
同じ言葉で話し合うのが始まり。
-
「ユビキタス言語」って何?やらないと何が困るの?
-
プロジェクト全員が同じ単語で同じものを指すための共通語。
これをやらないと、要件や実装で「同じ言葉なのに違う意味」になってバグや伝言ゲームが発生。
→ 会話・設計・テスト・コード、全部で辞書が共通になるのが大事。
-
Entity/ValueObject/Repositoryって、何のためにあるの?
-
Entity:IDや同一性を持つ「現場責任者」
ValueObject:不変で同じ値なら等しい「パーツ部品」
Repository:DBや外部サービスとの「仲介役」、でも詳細は隠す
この3つで「振る舞い」と「永続化」を分けて考える。
-
「集約(Aggregate)」ってどう使うのが正解?
-
「一つのまとまりで一貫性を守るグループ」。
外からは“ルート”越しにしか中を触れない。
1集約=1トランザクションが基本ルール。
-
「ドメイン貧血症」って何?なんでダメなの?
-
ドメインがあるということは振る舞いがあるはず。それを見つけられていない。
あとからUsecase書く時に見つけてドメインルールと気づかず実装してしまい黒魔術かしてしまう。
-
「軽量DDD」って何がダメなの?
-
形だけEntity/Repository作っても、
ビジネスの意味や言葉合わせが浅いと「DDDっぽいだけ」で現場が全く良くならない。
順番は「言葉合わせ→モデル化→実装」で。
-
どんな現場・チームに向いてるの?
-
ビジネス要件がややこしい/しょっちゅう変わる
複数のチームや部門で用語・ルールが食い違う
責任範囲の線引きで毎回揉める
-
モデル設計で詰まったときのコツは?
-
「なぜそう呼ぶのか?」をしつこく聞く(要ガッツ
今の設計に違和感があったら、業務の人に説明してみる
名前に悩んだら、そのまま業務エキスパートに相談(要ガッツ
論理と現場のズレをちゃんと認める
-
DDDやって本当に良かったことは?
-
開発・業務がクリアになりコミュニケーションコストが下がる(会話が活発になりいいもの作ろうって雰囲気になる)
あとから見返してもなぜこの設計?が説明しやすい

コメントを残す