【DDD実践】ドメインモデルの役割と設計指針｜Entityに寄りがちな設計をどう考えるか

投稿者 投稿日:

1. はじめに

ドメイン駆動設計（DDD）を学び始めると、必ず出てくるのが「ドメインモデル」という言葉です

一方で、

  • 結局Entityをたくさん作るだけになっている
  • ドメインモデルとDB設計の違いがよくわからない
  • Value ObjectやDomain Serviceの使いどころが曖昧

といった悩みを感じている方も多いのではないでしょうか？

この記事では、「DDDにおけるドメインモデルの役割とEntityに寄りがちな設計は問題なのか？」という点を、実務目線で整理していきます


2. ドメイン駆動設計における「ドメインモデル」の役割

DDDにおけるドメインモデルの役割を一言で表すなら、
業務の本質的なルールや知識を、コードとして表現する中心的な存在です

ドメインモデルは、

  • 画面やAPIの都合
  • DBのテーブル構造
  • フレームワークの制約

といったものから切り離され、業務そのものを正しく表すことを目的としています


3. ドメインモデルは「データ構造」ではない

DDDを始めたばかりの頃に陥りやすい誤解があります

よくある誤解

  • ドメインモデル = DBテーブルに対応するクラス
  • getter / setter しかないクラス
  • CRUD操作のための入れ物

この状態では、業務ルールはすべてApplication ServiceやControllerに散らばってしまいます


4. 本来のドメインモデル

DDDにおけるドメインモデルは、

  • 状態（State）
  • 振る舞い（Behavior）
  • 業務ルール（Rule）

をひとまとまりで表現します

たとえば、

  • 発送済みの注文はキャンセルできない
  • 合計金額が0円以下の注文は存在できない

といったルールを、
「使う側が気をつける」のではなく、モデル自身が守るのがポイントです


5. Entity・Value Object・Domain Serviceの役割

Entity（エンティティ）

Entityは以下の特徴を持ちます。

  • 識別子（ID）を持つ
  • 状態が変化する
  • ライフサイクルがある

代表例としては、

  • 注文
  • ユーザー
  • 契約

など、「業務上の主体」になりやすいものです

Value Object（値オブジェクト）

Value Objectは、

  • 識別子を持たない
  • 不変である
  • 値の等価性で判断される

という特徴を持ちます

金額、期間、メールアドレスなど、
ルールを含んだ「値」はValue Objectとして切り出すことで、
Entityが肥大化するのを防げます

Domain Service（ドメインサービス）

Domain Serviceは、

  • 複数のEntityにまたがる処理
  • 特定のEntityを主語にできない振る舞い

を表現するためのものです

例：

  • 料金計算
  • 与信チェック
  • 複雑な判定ロジック

「無理やりEntityに押し込まない」ための逃げ道として重要な存在です


6. Entityに寄りがちな設計はダメなのか？

結論から言うと「最初は寄りがちでOK」

DDDを学び始めると、ほぼ確実に以下の状態になります

  • ほとんどがEntity
  • Value Objectがほぼない
  • Entityが巨大化する
  • CRUD中心の設計になる

これは自然な成長過程です

問題なのは、
Entity中心の設計から一歩も進めないことです


7. Entity偏重を避けるための考え方

業務ルールを先に言語化する

「このクラスは何を保証するのか？」を言葉にします

  • いつ変更できるのか
  • どんな状態が禁止なのか

この時点で、
データ構造ではなく「ルール」から設計するのが重要です

「それ、値じゃない？」と疑う

以下に当てはまるものはValue Object候補です

  • 変更されない
  • ルールを持っている
  • まとまりがある

Value Objectを増やすだけで、ドメインモデルの表現力は一気に上がります

CRUDから考えない

画面・API・DBから設計を始めると、
ドメインモデルは必ずEntity中心になります

まず考えるべきなのは、

  • 業務で何が起きるのか
  • どんなイベントが発生するのか
  • 何が「できない」のか

です


8. 良いドメインモデルかを見極めるチェックポイント

  • Application Serviceにif文が溢れていないか
  • 不正な状態を作れない設計になっているか
  • メソッド名が業務用語になっているか
  • テストコードが仕様書のように読めるか

これらを満たしていれば、DDDらしいドメインモデルに近づいていると言えますね


9. 最後にまとめ！

  • ドメインモデルは業務知識の中心
  • データではなく「振る舞いとルール」を表現する
  • Entityに寄るのは自然な第一歩
  • Value ObjectやDomain Serviceで徐々にバランスを取る

DDDは一度で正解にたどり着くものではありません。
業務理解が深まるにつれて、モデルも進化していくものです


ぜひ参考ください！

是非フォローしてください

最新の情報をお伝えします

投稿者: Mon