ドメイン駆動設計はゲームに適していますか？

ドメインモデルについて読んだところですが、データのみを保持するクラス（ビヘイビア/メソッドが少ない）を持つゲームを開発して以来、それは私を啓蒙しました。これらのクラスを処理する仕事をマネージャーに割り当てました...そして今私のマネージャーは神のオブジェクトのように見えます。ロジックを処理することになっている私のゲームオブジェクトは、貧血ドメインモデルです。

私の現在のデザインパターンはシングルトンであり、これを実現するためにいくつかの再コーディングを行いたいと思います。（今のところ）ゲームでDDDを見たことがありませんが、これは良いアプローチですか？私はただの初心者プログラマーです（ゲーム開発者に傾倒しています）ので、ゲームを再設計するには肥大化する前に、優れたアーキテクチャーについてもっと学びたいです。

私はあなたの投稿の前にドメイン駆動設計について聞いたことがありません。こことここにあるいくつかの参考文献をざっと見てみると、これは、私が大学で教えた、オブジェクト指向プログラミングの伝統的な90年代のメソッドの派手な名前にすぎないように思われます。ソフトウェアでモデル化しようとしている状況では、ソフトウェアの構造が現実世界の概念の構造に従っているように見えます。

そのため、これに対する私の答えは、それは「良い」ものではないということです。これは通常妥当な出発点ですが、進むにつれて不十分であることがわかります。1つのソフトウェア内に単一のドメインが存在することはまれですが、いくつかの異なるドメインがあります。たとえば、ゲームのドメイン（ワールド、キャラクター、アイテム）、レンダラーのドメイン（シェーダー、メッシュ、マテリアル）、入力のドメイン（ファイルシステム、ネットワーク、キーボードとマウス）、およびドメインが重複して互いに影響し合う問題が発生します。多くの場合、2つのドメインを結合する過程で、実際には変更を必要とする依存関係があることに気づきます。つまり、表現の1つがヘルプよりも負担になります。

あいまいな例としては、コンソールの数学ライブラリやゲーム内のキャラクターなどがあります。数学ライブラリは、効率的に実行するために、大量のデータのリストと、そのリストで実行する1つの命令が必要です。ゲーム内のキャラクターはそれぞれ、レンダリングやアニメーションなどのための独自の頂点データのセットを持ちます。では、どのようにして、各キャラクターからすべての頂点データの長いリストを取得して、一度に処理できるようにしますか？遅いコピー操作を実行するか、代わりにキャラクターをリファクタリングして、データが数学ライブラリーによって処理されるようにすることができますが、ドメインの1つが別のドメインを優先するように分割されています。

個人的には、「Whatever-Driven-Design」に似たレーベルには警戒しています。ソフトウェアは、ソフトウェアを作成するための万能のアプローチが存在するには、範囲が広すぎ、複雑すぎます。代わりに、私ができる最高のソフトウェアを書こうとするとき、私はSOLIDの原則に頼ってフォールバックします。これらは、あなたが従い、魔法のように良いコードに到達できる方法の万能薬を約束することなく、あなたのコードがどれほど優れているかについての良い考えをあなたに与えます。残念ながら、そのような付属の方法論がない場合、これらのガイドラインに準拠する方法を学ぶには多くの経験が必要です。そのため、非常に多くの人が方法論を気に入っています。

貧血クラスとマネージャーオブジェクトの問題については、これは通常、オブジェクト指向の入門レッスンで説明されているものであり、特別な方法を使用して「修正」する必要はありません。（始めたばかりなら、オブジェクト指向プログラミングの本を手に入れたいかもしれません。）クラスは状態と振る舞いの結合であり、動作はその状態を変更し、これはカプセル化と呼ばれます。一般に、できるだけ多くのことをカプセル化しようとします。つまり、状態はオブジェクト自体（およびそのオブジェクトのみ）によって操作される必要があります。クラス内でモデル化できない動作の場合のみ、マネージャーなどの外部クラスに委任します。そのため、マネージャークラスの存在は、不十分に記述されたオブジェクト指向コードの兆候と見なされることがよくあります。

私の現在のデザインパターンはシングルトンであり、これを実現するためにいくつかの再コーディングを行いたいと思います。

その行が何を意味するのかわかりません。デザインパターンは、プログラムのごく一部を作成するためのよく知られた方法です。「現在の」設計パターンはなく、プログラムの残りの部分を形成することもありません。初心者にとっては、これらのパターンは正しい方向に進むのに役立ちますが、専門家にとっては一般的なコードの状況について伝えるための方法です。ただし、重要なことが1つあります。シングルトンはほとんど常に悪い考えであり、可能な限りそれらを回避する必要があります。このサイトやスタックオーバーフローでは、シングルトンに関する多くの意見を見つけることができますが、ここでは、シングルトンの必要性を回避するのに役立つ回答を含む実際的な質問を1つ示します。

パラダイム

この回答が書かれた時点では、ここに掲載されている他の回答はすべて間違っています。

ドメイン駆動設計がゲームに適しているかどうかを尋ねる代わりに。「ドメインモデリング」がゲームに適しているかどうかを確認する必要があります。

ドメインモデリングはゲームに適していますか？

答えは、時々それは絶対に素晴らしいです。ただし、プラットフォーマーやFPSなどのリアルタイムゲーム（多くの種類のゲーム）を作成している場合は、できません。これらのシステムには必ずしも適していません。ただし、ドメインモデルパターンの実装が効果的なゲームがシステム内に存在する場合があります。

他の人がここで述べたように、コンポーネントエンティティフレームワークは非常に人気があり、それには正当な理由があります。ただし、ゲーム開発文化では、階層化アーキテクチャーが明らかに不足しているようです。繰り返しますが、これは正当な理由によるものです。人々が開発する予定のほとんどのゲームは、エンティティの状態を単に変化させ、緊急の結果をゲームにします。

すべてのソフトウェアは、お客様が書いているソフトウェアではありません。他のものとはかなり異なるものもあります。

ドメインモデリングが適切に機能するドメインの例としては、カードゲーム、ボードゲーム、およびイベント駆動型の他のタイプのシステムがあります。

Xフレームレートで動作するゲームで、コアドメインの概念としてタイムデルタによって決定される動きなどは、おそらくあまり適していません。この場合、「ドメイン」は非常に単純なので、ドメインモデリングは必要ありません。衝突検出、新しいエンティティのスポーン、既存のエンティティへの力の影響などは、ほとんどのゲームプレイをカバーする傾向があります。

ただし、物事が複雑になると、特定のタイプの動作と計算を処理するために、エンティティ内にドメインモデルを実装する開発者を見るようになります。

ゲームアーキテクチャのドメインモデルパターン

多くの場合、ゲームエンジン（Unity3Dなど）はコンポーネントエンティティ指向です。プラットフォーマーでは、キャラクターのエンティティがあり、その状態は絶えず変化して位置などを更新します。

ただし、よりイベント駆動型のゲームでは、コンポーネントエンティティフレームワークの役割は、ユーザーインターフェイスとして存在するだけの可能性が高くなります。階層化されたアーキテクチャになります。

UIはゲームの状態をユーザーに表示します。ユーザーはUIを操作して、サービスレイヤーでコマンドをトリガーします。サービス層はドメインオブジェクトと対話します。ドメインオブジェクトがドメインイベントを発生させました。イベントリスナーはイベントを聞いて、UIで変更をトリガーします。

UI>サービスレイヤー>ドメインモデル

要するに、サービスレイヤー実装を備えたモデルビューコントローラーになります。

このアーキテクチャーを使用すると、完全に単体テスト可能なゲームコア（ゲーム開発文化では珍しいものであり、それは示されています）とイベント駆動型インターフェースを備えています。

では、DDDとは何ですか？

ドメイン駆動設計は、具体的には、ドメインについて学ぶために使用される分析パターンに重点を置いた文化/動きであり、実際に正しいものを構築し、次に実装パターンを表すモデルレイヤーを実装するための力を与える実装パターンです言語のイディオムを使用したドメインモデルの概念。DDDは、複雑なドメインで動作するコミュニティから生まれたものであり、ドメインモデリングに焦点を当てて、アプリケーションの高度な複雑さを管理する方法を常に模索しています。

DDDは、単にコーディングを開始し、システムをいじって、後で何を構築したいかを理解することなどが目的である場合、うまく機能しません。ドメインが存在することを前提としています。ですから、あなたのゲームがどうなるか分からないのなら、それではうまくいきません。

いいえ、DDDや他の「流行語」アーキテクチャはゲームに本当に適しているとは思いません。ここで本当に人気があるように思われる「コンポーネントシステム」の可能な例外を除いて。

このような質問や議論を聞くと、 このサイトをます。さまざまなアーキテクチャの流行語を熟考すると、通常、実際に独自のアプリケーションを設計およびコーディングするよりも効果が低下します。

はい、しかしあなたは適応すべきです。

DDDを使用すると、各ドメインのモジュール性と単一の責任が得られます。しかし、他のものは物事を複雑にするだけです。

ここで私の答えを見てください