この記事の途中に、以下の記事の引用を含んでいます。
If You Apply DDD to DDD, You Won’t Get DDD
DDDに憧れるエンジニアへ：「なぜこんなに難しいんだろう？」という壁
ドメイン駆動設計（DDD）という言葉に、あなたも一度は魅力を感じたことがあるのではないでしょうか。
複雑なビジネスの課題をスッキリ整理し、開発者とビジネスの溝を埋めてくれる──そんな夢を抱かせてくれる「青い本」、Eric Evansの『Domain-Driven Design』は、2003年の刊行から今もなお多くの技術者の心を掴み続けています。
しかし現実には、「DDDを理解できない」「難しすぎる」「結局使いこなせない」と感じて諦めてしまう人も多いのが実情です。
この記事 “If You Apply DDD to DDD, You Won’t Get DDD“は、その理由を私たちの思い込みとコミュニティの教え方そのものに見出し、根本から仕切り直すことの重要性を説いています。
驚きの主張：「DDDがDDD自身の原則を裏切っている」
この記事で最も印象的だったのは冒頭の主張です。
Domain-Driven Design (DDD) promises better software through a focus on the business domain and a shared understanding between developers and domain experts. … But if you actually apply this principle to DDD itself – asking what the domain is, what matters, what can be discarded – you won’t end up with what we call “DDD” today. You’ll end up with something much simpler.
つまり、DDDをDDDに適用してみる（DDDの「本質とは何か」「捨てられるものは何か」と自問してみる）と、いま「DDD」だと思われているものはとても複雑すぎる、本来はもっと単純なものに行き着く、というのです。
また、なぜDDDが普及しきれず、「難しすぎる」という印象を持たれるのか？について著者は次のように語ります。
“Instead of meeting developers where they are, we hit them with a wall of theory. Aggregates. Bounded Contexts. Value Objects. Entities. Repositories. … The terminology alone is intimidating. The concepts are abstract.”
「理論の壁」で多くの開発者をふるいにかけてしまっている現状への危機感が伝わってきます。
なぜDDDは本来「難しくあるべき」ではないのか
ここで一歩踏み込んで、DDDがなぜ「本当はもっとシンプル」であるべきか考えてみましょう。
DDDの誕生は「現実世界のビジネスロジック（ドメイン）にもっと近い形で設計・開発せよ！」という切実な思いから始まりました。
理論やパターンではなく、「現実の業務で使う言葉そのまま」にこだわり、開発者とビジネス担当者の会話から設計を始めること。
「ビジネス上の概念」を正しくプログラムで表現し、その違いを明確に分けて、「業務での混乱」や「誤解によるシステム障害」を未然に防ぐことこそが目的です。
にもかかわらず、実践コミュニティや業界の啓蒙のあり方は「先に用語やメソッドの一覧」を浴びせ、「パターンを覚え込ませる」ことに偏りがちです。
実際、記事にもこうあります。
“What started as a simple, human-centered idea – understand the domain, speak the language of the business – has become something that feels inaccessible to most developers.”
要するに、DDDの原則そのものが、実はDDD実践の現場で「ないがしろ」にされてしまっている、という逆説的な状況なのです。
パターンを覚えることが目的化する「形だけのDDD」批判
特に現代では、開発現場で「DDDっぽい言葉」や「有名な図」に触れる機会が増えました。
しかし、多くの現場では「やるべきパターンのチェックリスト」をなぞることで満足し、「肝心のドメイン理解」の本質的な努力を怠ってしまう“形だけのDDD”が横行しています。
記事でも次のように厳しく指摘されています。
“They treat it like a checklist.
‘Do we have Aggregates? Check. Do we have Value Objects? Check. Do we have Bounded Contexts? Check.’
But that’s not DDD. That’s pattern theater. It’s form without substance.”
これは、アジャイル開発の現場で「毎日スタンドアップミーティングをしているからアジャイルだ」と思い込むのと全く同じ、「儀式主義」の罠です。
本質はあくまで「チームとビジネス側の認識をズラさず、本当に価値のある開発サイクルを回す」ことなのに、外形だけ整えて「やった気」になる。
あなたの職場や過去のPJ経験でも、こうした「パターン演劇」に覚えがないでしょうか。
「ドメインと向き合う」ことの困難と、逃避としてのパターン消費
ここまで読んで、ではなぜ本来のDDDが難しいのか、その原因は“理論そのもの”というより、「人と向き合うしんどさ」にあることにも気づきます。
記事で強調されている重要なメッセージがあります。
“DDD is fundamentally non-technical. What it really demands from you is this:
Step out of your comfort zone.
Talk to domain experts – not just to gather requirements, but to truly understand their world.”
“It’s much easier to stay in the technical realm, where things are predictable and controllable.
And here’s the trap: the patterns give you a perfect hiding place.”
本当に理解するべきは「どうモデル化するか」以前に、「そもそもユーザーやビジネス部門が何をどう考え、どんな言葉で何を区別し、どんな困りごとを解決したいと思っているか」。
そのためには自分の快適領域（技術や図、用語といった手法）とは対極の、「他者と会話し、不確実性に向き合い、わからないことを素直に尋ねる」姿勢が求められます。
しかしこうした「人に向き合い、真摯に話を聞き理解を深める行為」こそ一番“楽ではない”ため、手近なパターン議論や技術論、ダイアグラム描画で忙殺されてしまう。
これが「コードは立派だが中身が空虚なDDDプロジェクト」の根本原因なのです。
目からウロコの提案：イベントソーシング（Event Sourcing）は立ち返りのヒント
記事の後半では、「イベントソーシング」という設計アプローチの自然さにスポットライトが当てられています。
“Here’s something I’ve noticed over the years: people understand events intuitively.
Events are how we naturally think about the world. …
When we recount history, we talk about events: the wall fell, the treaty was signed, the discovery was made. This isn’t a technical abstraction. It’s how humans process and communicate information.”
何が起きたか、どんな事実が積み重なったか、という“イベントベース”で物事を語ることは、人間のコミュニケーションやストーリーテリングとも直結しています。
さらに、イベントソーシングはDDDの入り口として理想的だとも指摘されています。
“Event sourcing isn’t just a way to store data. It’s also a surprisingly effective, lightweight entry point into the world of DDD. Why? Because it naturally pushes you in the right direction.”
- CRUD（Create, Read, Update, Delete）ではなく、「本当にビジネスで起きている出来事（PlaceOrder、ShipItem等）」を名付ける必要がある
- どのイベントがどこに属すか（アグリゲートの分割）、どのサービスがどのイベントを扱うか（バウンデッド・コンテキストの境界）等、理論を知らずとも現場で実作業として直感的に分割・設計が行える
- イベントはそのままでビジネスの現実を表現し、余計な理論や用語に頼らず本質へ近づける
技術パターンに振り回されず、「何が起きたか？」という問いで現場の会話をスタートさせること。
これは、シンプルに見えて非常に強力なドメイン把握の武器となり得ます。
私見：DDD最大の魅力と“誤解”の根源
記事を受けて、私自身も過去にDDDを学ぼうとして「パターン・用語の暗記」に苦しみ、「これができない自分は向いていないのでは」と自己嫌悪に陥った経験があります。
実際、IT業界では「パターンやフレームワークによる方法論のパッケージ化」が善とされがちで、「この設計パターンを使えば正解」といった“魔法のレシピ”志向が強くなりやすい。
しかしDDDが本来めざしたのは、「現場起点の知的生産のプロセス自体」をどう正直に進めるかという、技法以前の“文化”や“態度”の変革です。
「パターンを知らなきゃ即アウト」というプレッシャーや、「難解な理論で入り口を狭めること」こそが、その本質から遠ざかる最大要因だと言えます。
記事の「DDDをDDDに適用したら今の形態にならないはず」という逆説的な主張も象徴的です。
真にドメイン駆動であるべき設計アプローチは、その時々の業務や背景、現場の構成要素にあわせて“そぎ落とされ、純化”されていくべきもの。
“DDDらしさ”の判定基準が「パターン準拠度」になる現状は、DDD精神の「自己パロディ」にすぎません。
一度「本来のドメイン理解・現場との対話に徹する設計習慣」に立ち返り、「専門用語のドグマ」を手放す勇気が必要でしょう。
本質回帰への示唆：「現場の言葉」でシステムを組み立てる技術者になる
この記事が示唆する最大のポイントは、「犠牲にせずに済む“本当の開発の楽しさ”」は、ビジネスと開発との対話から生まれ、技法や用語の“型番”に閉じ込められるものではない、ということです。
実際、「イベントソーシング思考で物事を見直してみる」「ドメインエキスパートとの会話から本物の“言葉”を拾い、そのままコードに生かす」「CRUDを超えて、業務上重要な動詞にシステムが向き合う」──
これらは、特別な学位や何年もの経験がなくても、意識さえ変えれば明日から実践できる視点の転換です。
最後に記事の結びに寄せて──
“DDD was never meant to be complicated. We made it complicated. If we take DDD seriously – if we apply its own principles to itself – we have to admit: we’ve drifted from the core.”
今こそ“ドメイン駆動”の「ドメイン」そのものに立ち返り、「何が本当に重要か、どこまでそぎ落とせるか」を日々問い続ける技術者でありたいものです。
categories:[technology]
コメント