メシのタネ

メシのタネになる、Laravelや設計思想の技術配信サイト


DDDって急に言われた開発者のための雰囲気ガイド


  1. Architecture
  2. DDDって急に言われた開発者のための雰囲気ガイド

超要約

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

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

🧭 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やって本当に良かったことは?

開発・業務がクリアになりコミュニケーションコストが下がる(会話が活発になりいいもの作ろうって雰囲気になる)

あとから見返してもなぜこの設計?が説明しやすい


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

This site uses Akismet to reduce spam. Learn how your comment data is processed.