Android における Entity の寿命は短い

DDD で語られる Entity は、長い時間を生き続け、同一性を保ち続ける存在として説明されます。しかし Android アプリでは、この前提がそのまま当てはまることは多くありません。

  • 画面仕様の変更で形がすぐに変わる
  • API 仕様変更の影響を強く受ける
  • UI の都合で一時的な形に変換される

このような環境では、Entity を「長寿命で不変な存在」として扱おうとすると、設計が無理をし始めます。

本書では、Android における Entity を 「ID による同一性を持つが、形は変わりやすい存在」 と捉えます。寿命が短いことを前提にすることで、過剰な抽象化を避けられます。

Android で言われる Entity の多くは UI Model である

Android 開発では、データベースのテーブルや API レスポンスを 「Entity」と呼ぶことがよくあります。

これらは id を持っており、一見すると DDD における Entity のように見えます。 しかし実際には、DDD が想定する Entity とは異なる役割を担っていることがほとんどです。

Android で扱われるこれらのモデルは、

  • 画面の表示単位で生成される
  • UI の都合で形が頻繁に変わる
  • 状態を値として扱われる

といった性質を持ちます。

ここで使われる id の多くは、

  • RecyclerView や Jetpack Compose の key
  • 差分更新のための識別子

であり、時間をまたいだ同一性を保証するためのものではありません。

つまり、

id を持っているからといって、 それが Domain Entity であるとは限らない、ということです。

data class を恐れない

前節で述べたように、Android で「Entity」と呼ばれているものの多くは、 実際には UI Model や DTO に近い存在です。

この文脈において、Entity や Model を data class で表現することは、 DDD 的に見て必ずしも問題ではありません。

Immutable にこだわりすぎない

不変オブジェクト（Immutable）は、安全でテストしやすい設計として推奨されがちです。しかし Android では、Immutable にこだわりすぎることで、次のような弊害が出ることがあります。

  • copy の連鎖で意図が見えにくくなる
  • 状態更新の責務が分散する
  • パフォーマンスを過剰に気にする設計になる

重要なのは「不変であること」そのものではなく、どこで、誰が状態を変えてよいのかが明確であることです。

限定された範囲での Mutable な設計は、必ずしも悪ではありません。

sealed class / value object の使いどころ

Android では、sealed class や value object が非常に相性よく使えます。ただし、使いどころを間違えると、逆に複雑さを生みます。

  • 状態の種類が明確で、分岐を網羅したい場合 → sealed class
  • 単位や意味を値に持たせたい場合 → value object

すべてを sealed class にすれば安全、というわけではありません。状態の増減が激しい場合や、UI 専用の一時状態であれば、シンプルな enum や nullable で十分なこともあります。

UI Model と Domain Model を分ける意味・分けない意味

「UI Model と Domain Model は必ず分けるべきか」という問いには、明確な Yes / No はありません。

分ける価値があるのは、

  • 同じドメインを複数の画面で異なる形で使う
  • UI の都合で形が頻繁に変わる
  • Domain の判断を UI から隔離したい

といった場合です。

一方で、単一画面専用のシンプルなモデルであれば、無理に分けることで変換コードだけが増えることもあります。

本書では、「分けるかどうか」ではなく、なぜ分ける（分けない）のかを説明できるか を重視します。

Model 変換はドメインの責務ではない

Domain Model から UI Model への変換を、ドメイン層に置いてしまうケースがあります。しかし、これは責務の混同を招きやすい設計です。

UI 表現のための変換は、あくまで UI 側の都合です。ドメインは「どう見せるか」を知る必要はありません。

変換処理は、ViewModel や専用の Mapper に置くことで、ドメインの純度を保ちやすくなります。

この章のまとめ

Android におけるエンティティやモデル設計では、

  • 厳密さよりも変更耐性を重視する
  • data class や mutable を過度に恐れない
  • 分離は目的ではなく手段である

という姿勢が重要になります。

次章では、これらのモデルが Jetpack Compose の状態管理とどう接続されるのか を見ていきます。