ドメインとは「業務ロジック」のことではない

「ドメインとは何ですか？」と聞かれたとき、多くの人は次のように答えます。

  • 業務ロジックのこと
  • ビジネスルールのこと

これらは、完全に間違いではありません。しかし、この理解のまま設計を進めると、ほぼ確実にドメインは壊れていきます。

なぜなら、「業務ロジック」という言葉はあまりにも広く、そして曖昧だからです。画面遷移の条件も業務ロジックですし、APIを呼ぶタイミングも業務ロジックと言えてしまいます。その結果、「どこまでがドメインなのか」が誰にも説明できなくなります。

本書では、ドメインをもう少し狭く、そして厳密に扱います。

ドメインとは、そのシステムが守るべき判断とルールの集合です。

なぜ「判断」が重要なのか

システムが存在する理由は、計算をすることでも、画面を表示することでもありません。多くの場合、システムは「判断」をするために存在しています。

  • この注文は成立してよいか
  • この支払いは受け付けてよいか
  • この状態で次の操作に進んでよいか

これらはすべて判断です。そして、この判断には必ずルールがあります。もしルールがなければ、判断はできません。

DDDが注目するのは、この「判断」と「ルール」がどこに書かれているのか、そしてそれが守られているのか、という点です。

もし判断のロジックが、

  • UseCaseのあちこちに散らばっていたり
  • UI層に紛れ込んでいたり
  • 仕様書の文章にしか存在していなかったり

する場合、そのシステムは非常に壊れやすい状態にあります。

ドメインは「処理の流れ」を知らない

ドメインを設計するとき、多くの人が最初につまずくポイントがあります。それは、「ドメインは何を知っていて、何を知らなくてよいのか」という問題です。

結論から言うと、ドメインは処理の流れを知る必要はありません。

  • どの画面から呼ばれたのか
  • API経由なのか、バッチなのか
  • 同期処理なのか、非同期処理なのか

こうした情報は、ドメインにとって本質的ではありません。ドメインが知るべきなのは、「この状態で、この操作は許されるか」という一点だけです。

この切り分けができていないと、ドメインモデルはすぐに肥大化し、テストも困難になります。

ドメインとUseCaseの違い

DDDを学び始めると、ドメインとUseCaseの役割の違いが分からなくなることがあります。両方とも「業務の中心」を扱っているように見えるからです。

しかし、両者の責務は明確に異なります。

  • ドメイン：判断とルールを守る
  • UseCase：処理の流れを組み立てる

UseCaseは、「何を」「どの順番で」行うかを知っています。一方で、ドメインは「それをしてよいかどうか」だけを知っています。

もしUseCaseの中に大量のif文が現れ始めたら、それはドメインが本来持つべき判断をUseCaseが肩代わりしているサインです。

ドメインは中心に置かれるが、万能ではない

DDDでは、「ドメインを中心に置く」という表現がよく使われます。この言葉は非常に強く、誤解を招きやすい表現でもあります。

ドメインを中心に置くとは、

  • すべての処理をドメインに書くこと
  • すべてのクラスをドメインから呼ぶこと

ではありません。

中心に置くとは、「設計上の判断基準をドメインに寄せる」という意味です。このルールはドメインにあるべきか、それともUseCaseやUIにあってよいのか。その判断を常に意識することが重要です。

ドメインを見失った設計の末路

ドメインが曖昧なまま設計されたシステムでは、次のような現象が起こります。

  • 似たようなチェック処理があちこちに増える
  • 仕様変更のたびに複数箇所を直す必要がある
  • 「なぜこの条件があるのか」を誰も説明できない

これは、コードの問題というより、「考え方の問題」です。

DDDは、これらの問題を一気に解決する魔法ではありません。しかし、「どこにルールを書くべきか」という判断軸を与えてくれます。それだけでも、設計の寿命は大きく変わります。

次章では、ドメインをコードとして表現するための最初の道具である「モデル」について掘り下げていきます。