「ドメイン = ビジネスロジック」は半分間違い

「ドメインとはビジネスロジックである」

この説明は、間違いではありません。しかし、Android アプリ開発の文脈ではそれだけでは足りない、というのが本書の立場です。

Android アプリで頻繁に書かれているのは、次のようなコードです。

  • どの状態のときに、どの UI を出すか
  • どの条件を満たしたら操作を許可するか
  • どの値を正とみなし、どの値を無効とみなすか

これらは純粋なビジネスロジックとは言いづらい一方で、アプリとしての振る舞いを決定する重要な判断です。Android におけるドメインは、この「判断」を含んだ領域だと捉える方が、実態に近いと言えます。

Android のドメインは「判断」と「ルール」

本書では、Android におけるドメインを、次のように定義します。

アプリがどう振る舞うかを決める、判断とルールの集合

それは必ずしも、サーバー側のビジネスルールと一致する必要はありません。

  • 表示対象をどう選ぶか
  • ユーザー操作をいつ無効にするか
  • 状態遷移をどの順序で許可するか

これらは UI ロジックとも密接に関わりますが、UI そのものではありません。View や Compose の中に散らばると、変更時に全体像が見えなくなります。

UI ロジックとの境界線

「これは UI ロジックか、ドメインロジックか」という問いは、しばしば議論になります。しかし、白黒をはっきり分けようとすると、設計は硬直します。

本書では、次の問いを境界判断の基準にします。

  • この判断は、画面が変わっても同じか
  • このルールは、UI を捨てても意味が残るか

どちらか一方でも「Yes」なら、そのロジックはドメイン側に寄せる価値があります。逆に、特定の UI 表現に強く依存しているなら、UI 側に残した方が自然です。

Data 層にドメインを置いてはいけない理由

Android プロジェクトでは、ドメインロジックが Data 層に入り込んでしまうケースが少なくありません。

  • Repository 内で条件分岐が増える
  • API レスポンスをその場で解釈し始める
  • キャッシュ有無によって振る舞いが変わる

これらは一見便利ですが、結果として「なぜそうなるのか」が見えなくなります。Data 層は、あくまで データを取得・保存する責務 に集中させるべきです。

判断やルールを Data 層に置くと、テストもしづらく、UI 側からも追いにくい構造になります。

ドメインは薄くていい、でも曖昧にしてはいけない

Android におけるドメインは、Web や業務系と比べると、どうしても薄くなりがちです。それ自体は、悪いことではありません。

問題になるのは、ドメインが薄いことではなく、

  • どこにあるのか分からない
  • 何を担っているのか説明できない

状態になることです。

たとえ数個の関数やクラスしかなくても、「ここがアプリの判断を集約している場所だ」と言えるなら、それは十分にドメインです。

この章のまとめ

Android におけるドメインは、

  • 純粋なビジネスロジックだけではない
  • UI とデータの間にある「判断とルール」を担う

という位置づけになります。

次章では、このドメインを どのように UseCase や ViewModel と接続するのか、そして多くのプロジェクトが陥る「UseCase 地獄」をどう回避するかを具体的に見ていきます。