ドメイン駆動設計は、Wikipediaによると以下の説明がなされている。
ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり[1]、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである[2][3][4]。
DDDは以下のような目的に基づく。
プロジェクトにおける主な焦点を中核の業務領域と業務ロジックのレイヤーに置くこと 複雑な設計をドメインモデルで表現すること 技術者とドメインエキスパートの間にクリエイティブな協働関係を構築し、特定のドメイン問題を扱う概念的なモデルを継続的に洗練させること
ドメイン、つまり「アプリケーション化する対象のルールや仕様」のエキスパートの言葉に基づいてモデリングするわけだが、ドメインのエキスパートと言うからにはすでにドメインのもととなる仕様に精通している必要がある。少なくともこれから考えて思いつきで決めていくようなものではない。
その上で、継続的に洗練させていく、この営みがDrivenのはず。
業務系やWebといったゲーム以外のシステムは、基本的には現実世界の作業がもとにあり、それを電子化したものである。
現実世界で作業をしてた人がいたり、現実世界の作業が連想できたりするもので、そこにはそれに詳しい人、エキスパートと呼べる人が生まれる種がある。
では、どういうところがゲーム開発に向かないのか。
以下が理由である。
- 仕様の変化が激しい
- すでに決まった仕様さえ覆る
ドメインを成熟させるには、ドメインエキスパートと連携して、ユビキタス言語（誤解を生まないために言葉を統一）を持ってドメインを地道に積み上げていくなどの必要がある。
しかし、ゲーム開発では仕様の変化に対してそこまで悠長に開発を進めることはなかなか難しいし、やったことに対してバリューが得られない。そして、仕様の方向性が定まらないとドメインを洗練させることができない。
ドメインが不安定なのだ。
多くの場合（主にUnity界隈）、DDDと言ってアーキテクチャ図が出されるのは、DDDのサンプル設計図を参考にした「DSD（Domain Separation Design）」、ドメイン分離設計とでも言うべきものだと思う。
これが悪いと言う話ではない。ただDDDではないという話。
付け加えるなら、DDDのサンプル設計図は「DDDを目的とした場合のサンプル」であるということ。 DDDを見失ってDSDとなった場合、設計には然るべき変化が現れるはずだと思う。