2

多対多の関係のモデル化に関するいくつかの質問を見つけましたが、現在の問題を解決するのに役立つものは何もありません。

シナリオ

Users とsを持つドメインをモデル化していますChallenge。チャレンジには多くのユーザーがおり、ユーザーは多くのチャレンジに属しています。ユーザーがいない場合でも、課題は存在します。

ここに画像の説明を入力

十分に単純です。ユーザーはチャレンジでランク付けされる可能性があるため、私の質問はもう少し複雑になります。この情報は、ユーザーとそのランクのセットとしてチャレンジに保存できます。これもそれほど難しくありません。

質問

チャレンジでユーザーの個々のランクを照会したい場合 (チャレンジですべてのユーザーのランクを取得せずに)、どのスキームを使用すればよいですか? この段階では、データ アクセスでどのように呼び出しを行うかは気にしません。必要なランク データ ポイントが 1 つだけの場合に、何百ものランク データ ポイントを返したくありません。

また、ランク情報を保存する場所も知りたいです。ユーザーと課題の両方に依存しているように感じます。これが私が考えたものです：

  1. 明白なこと: をインスタンス化するときはChallenge、すべてのランク情報を取得するだけです。遅くなりますが動作します。

  2. 複合UserChallengeエンティティを作成しますが、それはドメインに反しているように感じます (「ユーザー チャレンジ」については触れません)。

    ここに画像の説明を入力

  3. 第三の選択肢？

私は 2 番に行きたいと思っていますが、これが本当に DDD アプローチであるかどうかを判断する自信はありません。

アップデート

、または何かUserChallengeのように、よりドメインに適したものを呼び出すことができると思いますか?RankUserRank

4

2 に答える 2

1

ここでの DDD アプローチは、ドメインの観点から推論し、ドメインの専門家/ビジネス アナリスト/モデルを改良するためにこの特定のポイントについて話し合うことです。エンティティの名前はユビキタス言語の一部であり、技術者ではない人々が理解して使用する必要があることを忘れないでください。したがって、「UserChallenge」はここで最も適切な用語ではないかもしれません。

私が最初にすべきことは、その「中間エンティティ」がドメイン モデルとユビキタス言語にふさわしいかどうかを判断することです。たとえば、Web サイトを構築していて、ユーザーがすべての課題と関連するランクのリストを表示できる専用のランキング ページがある場合、ランクはアプリケーションの重要な問題であり、ランキングエンティティはそれを表すのに良い選択です。ドメインの専門家に相談して、Rankings が適切な名前であるかどうかを確認するか、別の名前を使用してください。

一方、そのようなエンティティが必要であるという証拠がない場合は、オプション 1 に固執します。パフォーマンスの問題が心配な場合は、関係の多重度を減らす方法があります。Eric Evans は、その関連付けを修飾すると呼びます (DDD、p.83-84)。技術的に言えば、チャレンジにはマップ、つまりユーザーをキーとするランクの辞書があることを意味する場合があります。

于 2012-05-08T08:57:06.877 に答える
0

オプション 2 を使用します。「ユーザーの課題について話し合う」必要はありませんが、特定の課題についてすべてのユーザーを取得し、ランク別に並べ替える必要があります。それを行う方法！

于 2012-05-04T17:24:37.960 に答える