0

私は DDD を使用するプロジェクトに取り組んでいます。いくつかのクラスがあり、それらをどこに置くべきかわかりません。

ドメインは既存のゲームに関するものです。このゲームには、キャラクター、スキルツリーなどの基本的な概念があります。私のドメイン クラスは、これらの概念を単純に表したものです。私はこのゲームを作りませんでした。

私のアプリケーション/プロジェクトは、これらの概念を表現するソフトウェアに付加価値を加えることです。現時点では、名前と説明のみが可能な追加値です (たとえば、「火の魔道士」と「マナ依存、注意してください!」)。

質問 1 : 2 つのクラスを持つことは理にかなっていますか、それともそれらをマージする必要がありますか? 前者の場合、この「付加価値（名前と説明）付き」のクラスはどこに置けばいいのでしょうか？アプリケーション層で？

質問 2 : ドメイン レイヤーは、私が取り組んでいる知識の領域を表し、アプリケーション レイヤーは、ドメインには存在しないが付加価値として提供したいすべてのものを表します。

(したがって、ソフトウェアが単にドメインを表す場合、アプリケーション層は薄く、ソフトウェアがドメイン以外の機能を多数提供する場合、アプリケーション層は厚くなりますか?)

追加情報 1:私のプロジェクトは、キャラクター シミュレーターの作成に関するものです。したがって、キャラクターをシミュレートするには、キャラクターとそのすべての依存関係を表現する必要があります。私のドメイン層の責任は、ゲームを表現することです。これには、いくつかのプロパティ (Life、Mana、Attack、Defence、Class) を持つ Character などのクラスと、いくつかの列挙型 (使用可能なすべてのクラスをリストする CharacterClass など) が含まれています。

ここで、自分のプロジェクトで、ゲームのキャラクターを表すプロジェクトを作成する機能をユーザーに提供したいと考えています。プロジェクトでは、ユーザーは、現在のプロジェクトの名前、メイン (およびセカンダリ) 機器セット、メイン (およびセカンダリ) スキルツリーなどの追加情報を保存することもできます。装備セットやスキルツリーの注釈も利用できるので、ユーザーは簡単に組み込みのメモ/ポストイットを持つことができます。セカンダリ装備セットとスキル ツリー、注釈はゲーム内に存在しない概念です (したがって、私のドメインには存在しません)。

質問1の「付加価値のあるクラス」とは、複数の情報（キャラクター装備、スキルツリー、アノテーションなど）の集合体であるキャラクタープロジェクトです。ユーザーが必要に応じて、物理サポートに保存し、後で開いて編集することができます。

質問 1 の再定式化: Character クラスと CharacterProject クラスがあります。CharacterProject クラスは、複数の情報の合成です。しかし、それは私のアプリケーションに固有のものです。アプリケーション層、ドメイン層、または他の場所に配置することは理にかなっていますか?

4

1 に答える 1

0

最初の質問については、コメントして、謙虚な設計ガイダンスを提供したいと思います。謙虚な意味は、あなた自身の責任でそれを信じてください:D.

任意のレイヤーまたは任意のタイプのソフトウェアのクラスを設計している間、私は通常、一般化の愛（抽象化/インターフェイスの縮小など）でアプローチします。ドメインモデルのコアオブジェクトに追加される「値」である名前と説明があると述べました'SkillTree' や 'Character' など、IAdditiveInformation インターフェイスなどの名前と説明のクラスを一般化できるか自問してください。これら 2 つのクラスが行うことのほとんどが IAdditiveInfromation の一般化の下で共有/縮小できる場合、これがドメイン コアにもあることがわかります。このインターフェイスをドメイン モデルのコアで使用し、すべての依存関係をこのインターフェイスに向ける場合、次のような難しい投機的な設計上の質問に答える必要はありません。

  • 「値」クラスをさらに追加する予定はありますか?
  • 「GamePart」クラスはさらに追加されますか?
  • 「値」および「GamePart」クラスを設計して、それらの相互作用を最小限の労力で実装できるようにするにはどうすればよいですか?

ドメイン モデル、ドメイン サービス、またはアプリケーション層以降に配置するクラスを決定するため。これらをガイドラインとして使用します。

  • アカウント ソフトウェアが請求書に関連し、切り離すことができず、それなしでは機能しなくなるような方法で、クラスがソフトウェアが搭載されているものに直接関連している場合、そのクラスはドメイン モデル レイヤーにあり、タマネギの中核にあります。
  • クラスがコアでオブジェクトを操作し、ドメイン コアでのみ動作し、現在のコアのようなドメイン コアを使用するたびにオブジェクトを再利用できる場合。次に、それらはドメイン サービスです。
  • クラスがドメイン サービスおよび/またはドメイン コア上で動作し、そのアプリケーションに少し特化した感じがする場合。次に、おそらくアプリケーション層に属します。アプリケーション層にあるものについては、この機能はドメイン全体ではなく、ドメイン上の特定のアプリケーションにとって重要であることを覚えておいてください。したがって、そのアプリケーションにはこの機能のみが必要です。

少し分かりやすいように例を挙げてみます。

GPS ベースの追跡システムを想像してみてください。

  • 核となるのは、GPSTrackable というクラス (できれば抽象クラス) です。
  • ドメイン サービス レベルでは、GPSTrackable を操作/依存するクラスがあります。これは、GPS ボックスを指定すると、そのボックスに GPS トラッカブルを返す地理的位置ベースのクエリ コントロールです。このクラスを GPSTrackableQuery と呼びましょう

タマネギ/DDDの魔法と正しいOODを見る時が来ました:)。何のアプリかはまだ言ってないし、まだ決めてないです。アプリケーションに依存しない (理想的なアーキテクチャの方法で) 必要があるため、コア ドメインとドメイン サービスをキャプチャすることに決めていません。

これらをタマネギの核にして、

  • GPSTrackableQuery を 10 秒ごとに呼び出し、セキュリティ システムの軍事基地の近くにオブジェクトがあるかどうかをチェックするクラスをアプリケーション レイヤーで作成できます。そのコアを全員の電話で実行すると、ロケーション ベースのセキュリティ システムが得られます。 .
  • ユーザーが店の近くにいる人に大量の SMS または電子メールを送信したいときに GPSTrackableQuery を呼び出すクラスをアプリケーション層で作成できます。今、同じドメインコアから広告システムを作りました。

これに新しい例を追加できます。これは単純なことです。自分の決定を疑うとき、私は想像します。

最後に 1 つ: クラスをレイヤーに配置しても意味がないことも理解しておく必要があります。それらを「仮想」レイヤーに配置して、その責任と機能範囲を感じさせます。あまりにも疑わしい場合は、どこかに置くだけで、アーキテクチャ、設計、または実装が進化するときに、それが正しい配置であると感じるでしょう。

2 番目の質問について。

私の意見では、あなたの提案は正しいです。私がコメントできる唯一のことは、ドメイン層に知識の範囲という用語を使用しないことです（ドメインコアとドメインサービスの両方を意味すると思います）。私は、ドメイン コアを、コンピューター用語で表現した現実世界の知識、またはその背後にあるコア アイデアと見なしています。

于 2013-11-08T09:44:58.013 に答える