DDD のフルセットは Android には過剰になりやすい

DDD には多くの構成要素があります。Aggregate、Repository、Factory、Domain Service、Specification など…。これらは、複雑で長寿命なドメインを扱うシステムでは強力に機能します。

しかし、Android アプリの多くは、

  • 画面と状態の変更が中心
  • 要件の変化が早い
  • チーム規模が小さい

という前提のもとで開発されます。この文脈に DDD のフルセットをそのまま持ち込むと、構造はすぐに過剰になります。

ここで大事なのは、「DDD をどこまで削っても本質は残るのか」を見極めることです。

Android に必要なのは、この 3 つだけ

本書では、Android において最低限持ち込むべき DDD の要点を、次の 3 つに絞ります。

  • 境界（責務の分離）
  • 言葉（ユビキタス言語）
  • 変更に耐える構造

この 3 つが守られていれば、DDD の「考え方」は十分に機能します。逆に言えば、これ以外は文脈次第で捨てて構いません。

境界は「層」ではなく「理由」で引く

多くの設計議論では、「どの層に置くか」が主語になりがちです。しかし DDD の本質は、層ではなく変更理由にあります。

  • なぜ、このロジックはここにあるのか
  • どんな変更が入ったら、このコードを触ることになるのか

この問いに答えられる場所に、コードを置くべきです。

Android では、UI 変更とドメイン（意味やルール）の変更の頻度が極端に違うことが多く、層だけで境界を引くと責務が混ざります。本書では、「変更理由が違うものは分ける」という単純なルールを、設計判断の軸にします。

ユビキタス言語はクラス名よりも会話に現れる

ユビキタス言語というと、難しいドメイン用語を正確にクラス名に落とすことだと思われがちです。しかし、本当に重要なのは、チーム内の会話で言葉が揃っていることです。

  • その「状態」は何を指しているのか
  • 「有効」とは、どの条件を満たした状態なのか
  • 「未設定」と「空」は同じ意味なのか

これらが曖昧なまま実装が進むと、設計はすぐに崩れます。

本書では、ユビキタス言語を「コードを書く前に合意しておく言葉」として扱い、クラス設計よりも前段の思考として重視します。

変更に耐える構造とは「壊しやすい」こと

DDD の文脈では、「変更に強い設計」という言い方がよくされます。しかし Android 開発では、これは少し誤解を生みやすい表現です。

本書では、変更に耐える構造を、

壊しやすく、直しやすい構造

と定義します。

過剰に抽象化された構造は、一見すると堅牢ですが、実際には変更点を見つけにくく、修正コストが高くなりがちです。

Android では、将来を守るよりも、次の変更を素早く受け止められることの方が重要な場面が多くあります。

捨てていい DDD の要素、慎重に使う要素

ここで、本書の立場を明確にしておきます。

  • Aggregate：多くの Android アプリでは不要、または極小で十分
  • Factory：生成ロジックが複雑な場合のみ検討する
  • Domain Service：UseCase と役割が被るなら作らない
  • Repository：永続化抽象としてではなく、取得・保存の窓口として扱う

これらは「使ってはいけない」わけではありません。必要になったときに、理由を説明できるなら使う というスタンスで進めます。

この章のまとめ

DDD を Android に持ち込む際に重要なのは、

  • 型を守ることではなく、判断軸を持つこと
  • 完成形を目指すのではなく、変化に合わせて育てること

次章では、「そもそも Android におけるドメインとは何か」を掘り下げ、どこまでをドメインと呼ぶべきかを整理していきます。