あなたのDDDは間違っている

悲しいかな、ネット上では一部で誤ったDDD（ドメイン駆動設計）の認識が広まっており、その誤解を前提とした批判を目にすることがあります。 「完璧な設計」を目指すあまり、身動きが取れなくなっている開発者も多いのではないでしょうか。

この記事では、そういったDDDにおける「よくある間違い」を挙げ、それがなぜ間違っているのか、そして実践的で現実的なDDDへの向き合い方を解説します。

---

よくある間違いと誤解

必ずレイヤードアーキテクチャを採用しなければならないと思っている

これはよくある間違いで、コードをレイヤー分けしなかったからといってDDDではなくなりません。そもそもレイヤー分けるのはレイヤードアーキテクチャの考え方です。 DDDでは何らかのレイヤードアーキテクチャを採用することを 推奨 はしてますが、 必須 ではありません。

100%ドメイン知識に基づく実装、あるいは完璧なレイヤー分けが必要である

これも極端な誤解です。 現実のプロジェクトにおいて、実装するコードを100%純粋なドメイン知識のみで構成できません。

DDDの実践書である『実践ドメイン駆動設計（IDDD）』でも、パフォーマンスや技術的な制約、あるいは機能上の理由によって、純粋なモデリングを妥協し、実利をとるアプローチが複数箇所で示されています。 例えば、複雑な検索機能においてDBのパフォーマンスを最大限引き出す必要がある場合、無理にドメインオブジェクトを介さず、CQRSの考え方を用いて直接クエリを実行するなどの現実的な手法が推奨されています。DDDは、こういった妥協を許容しつつも、できるだけ中核となる業務ルールをクリーンに保とうとする現実的な考え方です。

生成AIによる開発の時代になったのだからDDDは必要ない

まったくもって逆です。 むしろ、生成AIによる開発の時代になったからこそDDDの重要性が増しています。

DDDはコードの書き方だけの問題ではありません。ドメインエキスパート（業務の専門家）と開発者がコミュニケーションを取り、「ユビキタス言語」を定義して適切にドキュメントやモデルに落とし込むという戦略的設計こそがDDDの真骨頂です。 そして、明確に定義された業務概念やルールは、生成AIにドメインを正確に理解させ、精度の高いコードを出力させるための 極めて強力なプロンプト（前提条件） となります。

Domain層の実装でEntityやValue Objectを無理に使わなくてもよい

これは半分正解で、半分間違いです。 小規模なプロジェクトや、単なるCRUD（データの登録・参照・更新・削除）で完結する機能であれば、EntityやValue Objectを無理に使う必要はありません。

しかし、それは「DDDの手法の中でEntityを使わない」のではなく、 「そのシステム（または境界）にはDDDを適用せず、トランザクションスクリプトやデータ駆動設計を採用する」 という技術的判断に他なりません。 もしDDDを適用して複雑な業務ルールに立ち向かうのであれば、同一性によって識別される「Entity」と、属性を表現する「Value Object」によるモデリングは、ドメイン知識をコードに表現するための必須の武器（戦術的設計）となります。

DBのトランザクションはインフラ層に閉じ込めなくてはならない

大間違いです。 Usecase層（アプリケーション層）でDBのトランザクション境界を管理するのは、妥協ではなくUsecase層の本来の責務です。

DDDにおいて、Usecase層の役割は「ドメインオブジェクト（集約）を呼び出して協調させること」と「ユースケースごとにトランザクションの境界（開始・コミット・ロールバック）を管理すること」です。 インフラ技術（SQLの記述など）を直接Usecase層に書くのはNGですが、トランザクションという制御の単位をUsecase層が決定するのは、アーキテクチャ上極めて正しい設計です。

---

何がDDDの条件になるのか？

ここまでの説明を見て、「じゃあ何をすればDDDといえるのか？」と思った人もいるでしょう。 結論から言うと、「業務ソフトウェアを作ること＝DDD」ではありません。

DDDとは、 「ソフトウェアの中心にドメイン（業務の複雑さ）を据え、それに立ち向かうためのアプローチ」 です。 具体的には以下の要素に取り組んでいるかが鍵になります。

• 開発者と業務専門家が同じ言葉（ユビキタス言語）を使い、それをコードの命名に反映させているか
• システム全体を一枚岩にせず、意味のある境界（境界づけられたコンテキスト）で区切っているか
• 業務のルールや制約を、UIやデータベースの都合から切り離して（ドメインモデルの隔離）実装しているか

裏を返せば、これらを放棄して「DBのテーブル構造ありきで設計する（データ駆動設計）」や「画面のボタンの裏側に直接ビジネスロジックを書く（スマートUI）」といった手法は、業務システムであってもDDDではありません。そして、複雑さのない単純なシステムであれば、無理にDDDを採用せずそれらの手法を選ぶことも立派な正解です。

---

まとめ

• DDDは設計の美しさや、開発者の潔癖症を満たすための銀の弾丸ではない
• 生成AI時代にこそ、業務知識を整理するDDDの「戦略的設計」が強力な武器になる
• パフォーマンスや現実の制約による妥協は積極的に行え。ただし、コアとなるドメインの純度を守るために、その妥協が本当に必要なのかは常に考えよ。