第9章：Android × DDD で起こりやすい設計の落とし穴

• Clean Architecture をそのまま持ち込んだ例
  • 何が起きたか
  • なぜ失敗したのか
  • 何を学ぶべきか
• UseCase が 100 個を超えたプロジェクト
  • 何が起きたか
  • なぜ失敗したのか
  • 何を学ぶべきか
• ドメイン層が util 層になった話
  • 何が起きたか
  • なぜ失敗したのか
  • 何を学ぶべきか
• テストしやすいはずが、誰もテストを書かない構造
  • 何が起きたか
  • なぜ失敗したのか
  • 何を学ぶべきか

この章では、Android アプリに DDD の考え方を真面目に適用しようとしたときに、構造上起こりやすい失敗例を取り上げる。

いずれも「考え方としては間違っていない」からこそ起きるものであり、設計を真剣に考えた結果として現れる。

Clean Architecture をそのまま持ち込んだ例

何が起きたか

Web や書籍で学んだ Clean Architecture を、そのまま Android アプリに適用したプロジェクトでは、

• presentation / domain / data が厳密に分離され
• すべての依存は内側に向き
• あらゆる処理が UseCase を経由する

という構造が作られた。

構造としては美しく、レビューでも「設計は正しい」と評価されていた。しかし、実装が進むにつれて次のような問題が顕在化した。

• ちょっとした画面修正でも複数レイヤーに修正が必要
• UI 変更のたびに Domain 側の調整が発生
• 実装コストが高く、改善のスピードが落ちる

なぜ失敗したのか

Clean Architecture 自体が悪いのではない。問題は、Android アプリの特性を考慮せずに、そのまま当てはめたことにある。

Android アプリでは、

• UI の変更頻度が高い
• 画面単位のロジックが多い
• 永続的な業務ルールが存在しないケースも多い

にもかかわらず、すべてを「安定した Domain がある前提」で設計してしまったことで、構造が過剰になった。

何を学ぶべきか

• Clean Architecture は 思想であって、実装テンプレートではない
• Android では「守りたい業務ルールがあるか」を先に見極める

UseCase が 100 個を超えたプロジェクト

何が起きたか

DDD を意識して「1 ユースケース = 1 クラス」を徹底した結果、UseCase クラスが 100 個を超えたプロジェクトがあった。

• 画面ごとに UseCase
• ボタン操作ごとに UseCase
• 初期表示・更新・削除で別 UseCase

結果として、

• パッケージを見ても全体像が分からない
• 似たような UseCase が大量に存在する
• 新しい実装時にどこに追加すべきか迷う

という状態に陥った。

なぜ失敗したのか

UseCase を「処理の単位」ではなく「クラスを作るルール」として扱ってしまったことが原因である。

本来 UseCase は、

• アプリケーションとして意味のある操作
• 業務的な判断を伴う処理

を表現するための概念だ。単なる CRUD や画面操作まで UseCase 化したことで、構造がノイズに埋もれてしまった。

何を学ぶべきか

• UseCase は 増やすものではなく、選ぶもの
• 「これは本当に業務的な判断か？」を問い続ける

ドメイン層が util 層になった話

何が起きたか

Domain 層を Android 非依存に保とうとした結果、

• フォーマット変換
• バリデーション
• 並び替えロジック

といった処理がすべて Domain に集約された。

一見すると Domain は純粋でテストもしやすい。しかし実態は、

• どの処理が業務ルールなのか分からない
• 画面都合のロジックも Domain に存在する

という 巨大な util 層 になっていた。

なぜ失敗したのか

「Android に依存していない = Domain」という短絡的な判断が原因である。

Domain 層は、

• 業務上の意味
• ルール
• 制約

を表現する場所であって、「置き場所に困ったロジック置き場」ではない。

何を学ぶべきか

• Domain に置く基準は 技術ではなく意味
• 業務的な意味を説明できない処理は、Domain 以外に置く

テストしやすいはずが、誰もテストを書かない構造

何が起きたか

DI と DDD を導入し、

• 依存はすべて interface 経由
• Domain は純 Kotlin
• モックも簡単

という「テストしやすい構造」が完成した。

しかし現実には、

• テストコードはほとんど書かれない
• 書かれてもメンテされない

という状態だった。

なぜ失敗したのか

構造としてテスト可能であることと、テストを書く動機があることは別であるためだ。

• UseCase が細かすぎてテストの価値が低い
• テストを書いても仕様変更ですぐ壊れる
• 何を守るテストなのか分からない

こうした状況では、誰もテストを書き続けられない。

何を学ぶべきか

• テストしやすさは 目的ではなく手段
• 「何を守りたいのか」を先に決めないと、テストは定着しない

本章で紹介した失敗例は、どれも「設計を良くしよう」とした結果として起きている。だからこそ重要なのは、

• 型や構造を整えることよりも
• 判断基準を共有すること

である。