はじめに

はじめに

「DDD（ドメイン駆動設計）は Android には重い」

おそらく多くの Android エンジニアが、一度はそう感じたことがあるはずです。

Clean Architecture を参考に層を分け、UseCase を作り、Repository を定義し、気づけばクラスは増え続け、変更はむしろやりにくくなっている──そんな経験は珍しくありません。

一方で、Web や業務系の世界では「DDD は当たり前」のように語られています。その温度差の中で、Android エンジニアはこう悩みます。

• DDD をやらないと設計力が低いと思われるのではないか
• でも、全部やると明らかにオーバーエンジニアリングになる
• 結局、どこまでやれば“正解”なのか分からない

本書は、その迷いに対する 現実的な答え を提示するために書きました。

ここで扱う DDD は、教科書的なフルセットの DDD ではありません。Aggregate Root を厳密に守る話も、巨大なエンタープライズシステムを前提とした話も、基本的にはしません。

代わりに本書が重視するのは、次の一点です。

Android アプリという制約の中で、設計が“役に立つ”状態をどう作るか。

Android アプリ開発は、UI と状態の変更が中心です。仕様変更の多くは画面に現れ、非同期処理とライフサイクルが複雑さを生みます。この文脈を無視したまま DDD の型だけを持ち込むと、設計はすぐに形骸化します。

本書では、DDD を「守るべきルール」ではなく、「判断のための視点」として扱います。

• どこに境界を引くと変更が楽になるのか
• どの責務はドメインに置く価値があり、どれは置かなくていいのか
• なぜその設計を選んだのかを、言葉で説明できる状態とは何か

これらを、Android の実装文脈と結びつけながら解説していきます。

想定読者は、次のような方です。

• MVVM や Clean Architecture は一通り実装したことがある
• UseCase や Repository を作ってはみたが、しっくりきていない
• 「設計が大事なのは分かるが、何が大事なのか分からない」と感じている

逆に、DDD の原理や用語を網羅的に学びたい方や、厳密な理論体系を求める方には、本書は向いていないかもしれません。

この本のゴールは、あなたが次に設計をするとき、

「Android アプリという文脈で、なぜこの構造にするのか」を自分の言葉で説明できるようになること。

そして、設計がプロダクトの足かせではなく、変更に耐えるための武器 になることです。