ざっくり一言で

  • ドメイン (Domain) → 解こうとしている「問題そのもの・業務の世界」

  • モデル (Model) → そのドメインを理解・表現するために人間が作った「写像（抽象化）」

もう少し噛み砕くと

ドメインとは何か

ドメインは コードでではありません 。

  • 業務ルール
  • 制約
  • 用語
  • 価値判断
  • 現実世界で「そうなっている理由」

たとえば口座振替アプリなら：

  • 「引き落とし元口座は必ず1つ存在する」
  • 「同じ支払先に対して複数の引き落とし元は持てない」
  • 「金額は0円以上でなければならない」

これ全部 ドメイン。まだコードの話は何も出てきてません。

モデルとは何か

モデルは、そのドメインを扱うために作る表現です。

  • Entity
  • Value Object
  • Aggregate
  • ドメインサービス
  • それらの関係性

例：

data class DirectDebit(
    val sourceAccountId: AccountId,
    val destination: Destination,
    val amount: Money
)

これは「口座振替」という現実の概念を、プログラムで扱える形に落としたもの。

これが ドメインモデル。

よくある誤解ポイント

「ドメイン = ドメインモデル」

これは 半分正しくて半分間違い。

  • ドメイン → 現実世界・業務世界そのもの
  • ドメインモデル → それを 近似 したもの

モデルはあくまで「モデル」なので：

  • 省略しているものがある
  • 嘘（近似）が含まれる
  • ユースケースや文脈ごとに違う形になり得る

Evans 本の有名な一文

The model is not the domain.

モデルはドメインそのものではない。 ドメインを理解するための道具にすぎない。

これを忘れると

  • 「このクラス設計がドメインだ」
  • 「コードが現実を支配し始める」
  • 設計変更＝世界観の崩壊、になる

モデルに種類があるのはなぜか

  • ドメインは 画面遷移やUIとは無関係
  • モデルは 永続化や通信形式とも本来は無関係
  • UI都合でモデルを歪めると → ドメイン理解が壊れる

だから、

  • DB Entity
  • API DTO
  • Domain Model

を分ける意味が出てきます。

全部「モデル」だけど、見ているドメインの切り取り方が違う

まとめ

  • ドメイン → 「この世界では何が正しいか」
  • モデル → 「それを扱うための表現」
  • ドメインモデル → ドメイン理解をコードに落とした近似図

そして一番大事なのは：

モデルは育て直せる。でもドメインを見失ったら終わり