メインコンテンツまでスキップ

🧩 Anemic Domain Model（貧血モデル）

✅ このスタイルの概要​

データ（プロパティ）だけを持ち、ビジネスロジック（振る舞い）がサービス層に分散してしまった「貧血状態」のドメインモデル。
DDD では典型的なアンチパターンとして扱われる。

✅ 解決しようとした問題（表向きの理由）​

Anemic Domain Model は、以下のような“分かりやすさ”を求めた結果として生まれる：

  • ドメインオブジェクトは 純粋なデータ構造 にしたい
  • ビジネスロジックは サービスクラスにまとめたい
  • DTO のようにシンプルなオブジェクトを扱いたい
  • ORM やフレームワークと相性がよい（POJO/POCO のまま扱える）

しかし、これらのメリットは往々にして以下の問題を生む：

  • ビジネスルールが複数サービスに分散してしまう
  • 不変条件の保証が困難
  • 「どのサービスが何の責務なのか」が曖昧になる

✅ 基本思想・実態​

典型的な Anemic Domain Model は以下の構造：

● ドメインクラス（Entity / Value Object）​

  • プロパティだけを保持
  • メソッドは getter/setter 程度
  • 状態遷移ロジック・ルールは持たない

● サービスクラス（Domain Service / Application Service）​

  • ドメインモデルを引数に取り、状態を変更
  • 不変条件・ルール・計算ロジックが散らばる
  • サービス間でロジックが重複しがち

結果として ドメインモデルが“ただのデータ”になり、整合性が崩れやすい。

✅ 得意なアプリケーション​

「アンチパターン」ではあるものの、次のような場面では現実的な選択になり得る：

  • ドメインルールが単純で、複雑な状態遷移が存在しない
  • ほぼ CRUD 中心のミニマムな業務アプリ
  • 期限が短く、素早く動く機能が必要な場合
  • フレームワークがデータ中心設計を強く前提にしている場合（Rails など）

→ 複雑さが低いことが前提条件。

❌ 不向きなケース​

以下のようなアプリでは確実に破綻する：

  • 状態遷移や不変条件が重要なドメイン
  • 高い整合性が求められる領域（金融・決済・在庫管理・物流など）
  • 再利用される複雑なビジネスロジックが多い
  • 長期運用で仕様変更が頻繁に発生するプロダクト

典型的な問題：

  • どこにロジックを書いたか分からない
  • テストが書きづらい（サービス層が膨張）
  • バグが再発しやすく、修正範囲が読みにくい

✅ 歴史（系譜・親スタイル）​

  • データ中心志向（Active Record / Table Module）的な設計から自然発生した構造
  • DDD の文脈で、Evans が「貧血モデル」として問題提起
  • Rich Domain Model（リッチドメイン）や DDD のアプローチは、この問題への対抗として発展

✅ 関連スタイル​

  • Active Record / Table Module
    データ中心の親戚スタイルで、貧血モデル化しやすい
  • Domain Model（リッチドメイン）
    貧血モデルの問題を解決する“対極”のアプローチ
  • Service Layer
    貧血モデルと密接な関係がある（ロジック過剰集中の原因にもなる）

✅ 代表的なフレームワーク​

Anemic Domain Model は “特定フレームワークで採用される” というより、
データ中心設計が強いフレームワークで“自然発生”しやすい構造。

  • Rails / Laravel（Active Record 中心）
    モデルにロジックを載せきれず、サービス層に散りがちな構造が生まれやすい。

  • Django
    MVT 構造でドメインロジックが view/service に寄りやすい。

  • ORM が POJO/POCO を前提にする環境（Java/.NET）
    Entity がデータ保持だけになりがちで、ドメインロジックが外へ逃げるケースが多い。

✅ このスタイルを支えるデザインパターン​

Anemic Domain Model はパターンとして“推奨される構造”ではないが、
補助的に次のパターンが登場する。

  • Command
    複雑なロジックがサービス層に溜まった際、操作単位で整理するために使われる。

  • Strategy
    ドメインロジックがサービス側に集まるため、差し替え可能なロジック整理に使われる。

  • Template Method
    複数サービスで重複する処理ステップを統一する必要が生じたときに使われる。

✅ まとめ​

Anemic Domain Model は、
「分かりやすい」「実装しやすい」という理由で採用されがちだが、
複雑なドメインには決して向かず、構造の崩壊を加速させる危険がある。

重要なのは：

「このアプリのドメインの複雑度は、
Anemic Model のシンプルさで済むのか？」

という問いを常に投げかけること。

複雑さが少しでも増える兆候があるなら、
Domain Model / DDD / Layered / Hexagonal など、
より本格的な構造スタイルを検討すべきだ。