超要約

ビジネスの複雑さをコードで正しく映すための“言葉合わせ”と“責任の境界線”が DDD の核心だよ。

「DDD って概念だけは聞いたことあるけど、何が嬉しいの？」――そんなキミに贈る、一気読みで分かる 戦術的×戦略的 DDD 超入門。難解な理論をできるだけ日本語のままシュッと落とし込みます。

🧭 DDD の主な目的

ビジネスの複雑さをコードに正しく反映 すること。

• ドメイン (= ビジネス領域) へ集中した設計を促す
• フレームワークやデータストアに引っ張られない“純粋ロジック”の温存

🚩 ― 実装とビジネスの言語ギャップがバグも技術的負債も生むから。

🗣️ ユビキタス言語 (Ubiquitous Language)

定義：プロジェクト全員が 同じ単語で同じ概念を指す ための共通語彙。

✔️ どうして重要？

• コード・テスト・会話・設計図が一枚の辞書を共有し、誤解を根本から削減
• 仕様変更時も「言葉」を追うだけで影響範囲が見える

💡 Tip — 名前付けに悩んだらドメインエキスパートに 1 分インタビューしよう。「この概念、業務ではなんて呼びます？」

🧱 ドメインモデル vs. データモデル

SQL の JOIN 地獄をドメイン層に持ち込むと、途端に “データモデル内乱” が起きるから注意だよ

🧍 エンティティ (Entity)

識別子 (ID) を持ち、ライフサイクルと同一性を扱うオブジェクト。

• 振る舞いと状態を抱え込む「現場責任者」的存在

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 の黄金パス
• 小さなコンテキストから試して、成功体験 をチームに輸血しよう
• 次は イベントストーミング で要件を可視化してみるとさらに理解が深まるかも？

ぼくもイベントストームで付箋ペタペタ貼りたい〜！