なぜ「DDDは難しい」と言われるのか

「DDD（ドメイン駆動設計）は難しい」──これは、多くのエンジニアが一度は口にする言葉です。実際、DDDに関する書籍や記事を読み、Entity、Value Object、Aggregate、Repositoryといった用語を学んだにもかかわらず、「で、実際のプロジェクトでどう使えばいいのか分からない」という感覚を抱いた人は少なくないでしょう。

しかし、本当にDDDそのものが難しいのでしょうか。筆者は、DDDが難しく感じられる最大の理由は、「DDDが何であるか」を学ぶ前に、「DDDが何ではないか」を十分に理解しないまま、表面的な技法だけを適用しようとしてしまう点にあると考えています。

DDDは、フレームワークでも、設計パターン集でもありません。ましてや、Entityクラスを作り、Repositoryインターフェースを定義すれば完成するようなチェックリストでもありません。にもかかわらず、多くの現場では、DDDが「特定のクラス構成」や「お作法の集合」として誤解されたまま導入されています。

この章ではまず、DDDを正しく理解するための第一歩として、「DDDとは何ではないのか」を整理します。これはDDDを否定する章ではなく、むしろDDDの本質に近づくために、不要な誤解を一つずつ取り除いていくための章です。

DDDは「EntityとValue Objectを作ること」ではない

DDDの説明として、最もよく見かけるのが次のようなものです。

  • IDを持つものが Entity
  • 値で同一性を判断するものが Value Object

これ自体は間違いではありません。しかし、この説明だけを鵜呑みにしてしまうと、「DDD = EntityとValue Objectを定義すること」という非常に危険な短絡に陥ります。

実際の現場では、次のようなコードをよく目にします。

  • ただのDTOにすぎないEntity
  • ロジックを一切持たないValue Object
  • 生成されるが、ほとんど使われないドメインモデル

これらは、DDDの用語を使ってはいるものの、DDDの考え方はほとんど反映されていません。EntityやValue Objectは、DDDの「結果」であって「目的」ではないのです。

DDDが本当に扱おうとしているのは、「そのシステムにおいて、何が重要で、何を守るべきか」という問いです。EntityかValue Objectか、という分類は、その問いに答えた結果として自然に現れるものにすぎません。

DDDは「Repositoryをinterfaceにすること」ではない

DDDやClean Architectureの文脈で、Repositoryはしばしば次のように説明されます。

  • 永続化処理を隠蔽する
  • データベースへの依存を排除するためにinterfaceを切る

これも一部は正しいのですが、ここでも「手段」が「目的」にすり替わる危険があります。Repositoryをinterfaceにした瞬間にDDDが成立するわけではありません。

Repositoryの本質的な役割は、「ドメインモデルのコレクションとして振る舞う」ことです。データベースの都合ではなく、ドメインの言葉でモデルを取得・保存できるようにする。その結果として、永続化の詳細が隠蔽されるのであって、interfaceを切ること自体が目的ではありません。

もしRepositoryが、単なるCRUD操作のラッパーになっているのであれば、それはDDD的なRepositoryとは言いがたいでしょう。

DDDはClean Architectureと同義ではない

DDDの話題になると、必ずと言っていいほどClean ArchitectureやHexagonal Architectureといった言葉が並びます。そのため、「DDD = Clean Architecture」だと誤解されがちです。

しかし、両者は扱っているレイヤーが異なります。DDDは「どうモデルを考えるか」「業務の本質をどうコードに落とすか」という思考法であり、Clean Architectureは「依存関係をどう制御するか」という構造の話です。

両者は相性が良く、組み合わせて使われることも多いですが、同一ではありません。Clean Architectureの形を整えただけでは、ドメインが貧血状態のまま放置されることもあります。

つまり、DDDはアーキテクチャ図を描く前に始まっているのです。

なぜ設計は時間とともに壊れていくのか

多くのプロジェクトでは、開発初期の設計はそれなりに整っています。しかし、機能追加や仕様変更を繰り返すうちに、次第に次のような状態に陥ります。

  • 条件分岐だらけのUseCase
  • あちこちから呼ばれる共通関数
  • 変更の影響範囲が読めないコード

これは、エンジニアの技術力不足だけが原因ではありません。設計が「変更に耐えられない形」で作られていた場合、どれだけ注意深く書いても、いずれ破綻します。

DDDは、この「変更によって設計が壊れていく問題」に正面から向き合うための考え方です。どこにルールを閉じ込め、どこを変更可能にするのか。その境界を明確にすることが、DDDの出発点です。

この本で扱うDDD

本書では、DDDを「銀の弾丸」としては扱いません。また、すべてのプロジェクトにDDDを適用すべきだとも主張しません。

本書で扱うDDDは、次の問いに答えるための道具です。

  • なぜこのロジックはここにあるのか
  • なぜこの変更は怖いのか
  • なぜ設計を説明できないのか

これらの問いに向き合う準備ができたとき、DDDは初めて意味を持ちます。

次章では、「ドメイン」とは何か、そしてなぜそれが設計の中心になるのかを、もう一段深く掘り下げていきます。