DDD は「最初から完成させるもの」ではない

DDD という言葉には、どうしても「最初にきれいな構造を作らなければならない」という印象がつきまといます。

  • ドメイン層を用意する
  • UseCase を定義する
  • Repository を抽象化する
  • Entity を厳密に設計する

これらを 一気に やろうとした瞬間、設計は重くなります。 そして多くの場合、その重さに耐えきれず、DDD は「途中で放置される構造」になります。

本書が提案する DDD の始め方は、その逆です。

最初から正解を作らない。 あとで壊す前提で、小さく置く。

いきなりドメイン層を作らない

DDD を始めようとすると、真っ先にやりたくなるのが「domain パッケージを作ること」です。 しかし、これはもっとも失敗しやすい第一歩でもあります。

理由は単純です。

  • 何がドメインなのか、まだ分かっていない
  • どこが変わりやすいか、まだ見えていない
  • 判断とロジックがどこに集まるか、まだ確信がない

この状態でドメイン層を作ると、そこはすぐに “よく分からないコード置き場” になります。

本書では、次のような始め方を推奨します。

  • まずは ViewModel と Repository だけで作る
  • 判断ロジックを「ここ怪しいな」と思う場所に集める
  • それが固まり始めたら、初めて「ここがドメインだ」と名付ける

ドメインは作るものではなく、浮かび上がってくるもの です。

境界を 1 箇所だけ決める

DDD を導入しようとすると、つい「すべての境界を正しく引こう」としてしまいます。

  • UI と Domain
  • Domain と Data
  • UseCase と Repository
  • Entity と Model

しかし、最初から全部やる必要はありません。

最初にやるべきことは、たった一つです。

「ここだけは守る」という境界を 1 箇所だけ決めること

たとえば、

  • Repository に判断を書かない
  • ViewModel にビジネスルールを書かない
  • UI から DataSource を直接触らない

どれでも構いません。

重要なのは、境界の数ではなく、理由が説明できるかどうか です。

1 箇所でも「ここを越えない」と決められると、設計は自然と整理され始めます。

言葉を揃えるところから始める

DDD というと、クラス設計やパッケージ構成に意識が向きがちですが、もっと簡単で、もっと効果的な入り口があります。

それが 言葉を揃えること です。

  • この「状態」は何を指しているのか
  • 「有効」と「利用可能」は同じ意味か
  • 「未設定」と「空」はどう違うのか

これらが曖昧なまま実装が進むと、どんなに構造を整えても設計は崩れます。

逆に言えば、

  • 仕様書
  • 会話
  • コメント
  • 変数名

ここで使われる言葉が揃ってくると、設計は勝手にそれっぽい形になります。

DDD はコードを書く前から始まっています。 そして、言葉を揃えるのは、もっともコストが低く、効果が高い第一歩です。

リファクタリング前提の設計

本書で一貫している前提があります。

Android アプリの設計は、必ず後から壊される。

  • 仕様は変わる
  • UI は変わる
  • API は変わる
  • 優先度も変わる

この現実を無視して「完成形」を目指すと、設計はすぐに破綻します。

だからこそ、本書では次の姿勢を強く推奨します。

  • 最初は雑でもいい
  • でも、意図は残す
  • 壊すときに理由を説明できる構造にする

リファクタリング前提で設計するというのは、「いい加減に作る」ことではありません。

「どこを壊すかが分かるように作る」 ということです。

小さく始めた DDD は、あとから育てられる

DDD は、一度導入に失敗すると「もう二度とやりたくないもの」になりがちです。 その多くは、最初からやりすぎたことが原因です。

  • 型を揃えすぎた
  • 層を作りすぎた
  • 将来を考えすぎた

本書が勧めるのは、その真逆です。

  • まず 1 箇所だけ守る
  • 言葉を揃える
  • 判断が集まったら名前をつける

この順序で始めた DDD は、途中で投げたくならない し、 必要になったときにだけ、自然に拡張できます。

この章のまとめ

DDD を Android に持ち込むときに、もっとも重要なのは、

  • 小さく始めること
  • 最初から正解を求めないこと
  • 壊す前提で作ること

です。

DDD は、導入した瞬間に価値を生むものではありません。 変更が起きたときに、初めて差が出る設計思想 です。

次章では、ここまでの考え方を踏まえた上で、 「DDD を 採用していると言える状態 とは何か」 を実例を通して確認していきます。