0

スポーツ イベントをモデル化するドメイン モデルでは、このシナリオをどのように処理する必要がありますか。特に、データを保持するために SQL ドキュメント データベースを使用しないというコンテキストでは。

システムの主なエンティティは、シーズン、トーナメント グループ、トーナメント、トーナメント ステージ、マッチ、プレーヤーです。

シーズン - シーズンには、開始日、終了日、順序付けられた Player のコレクション、および Tournament のコレクションがあります。

トーナメント グループ - トーナメント グループにはトーナメントのコレクションが含まれます。各トーナメントは 1 つのトーナメント グループにのみ属することができます。これが実際にエンティティであるべきかどうかはわかりません。

トーナメント - トーナメントには、開始日、終了日、プレーヤーの順序付けられたコレクション、トーナメント ステージの順序付けられたコレクションがあります。

トーナメント ステージ - トーナメント ステージには、Match の順序付けられたコレクションがあります。トーナメントで試合をグループ化するための単なる方法であるため、これがエンティティであるべきかどうかはわかりません。

Match - Match には Player のコレクションが含まれます。

これまでのところ、集約ルートはシーズンであると言うでしょうが、プレーヤーがこのモデルのどこに適合するのかわかりません。また、おそらくトーナメント グループを適切に扱っていない可能性もあります。 .

統計は、シーズン、トーナメント グループ、およびプレイヤーに対して生成する必要があります。たとえば、シーズンで最も多くのスコアを獲得したプレイヤー、トーナメント グループで最も多くのスコアを獲得したプレイヤー、およびどのトーナメント、シーズン、またはトーナメント グループで最も多くのスコアを獲得したプレイヤーについてです。

このデータを取得するには、Player エンティティが Tournament と Match への参照を保持する必要があると考えていましたが、これらの参照は Season によっても役立ちます。これは受け入れられますか? また、別の集計ルートでデータが変更された場合にデータを更新するための最良の戦略は何ですか?

4

1 に答える 1

1

あなたが説明することのほとんどは、動作が何であるかのヒントを含むドメインの用語集であるため、答えるのは簡単な質問ではありません(ただし、その動作に重要性はありません)。モデルがサポートしなければならない各シナリオ(これまでに知っていること) を書き留めてから、それらのシナリオのそれぞれを実装しようとしてそのモデルを作成し、挑戦し、進化させるとしたら、それとはまったく異なるものになってしまうでしょう。は上記で説明されています。おそらく、それぞれが異なる側面を解決する複数のモデル。集約は、一連のエンティティと値オブジェクトを中心とした動作のクラスターであり、動作を後付けしようとする名詞としてのエンティティではありません。

何かアドバイスをするなら、シーズンやトーナメントなどの管理と、実際のシーズン中に何が起こったかを実際に記録すること、シーズン中またはシーズンの終わりに導き出したい統計の種類を報告することとを分けてください。シーズン。

于 2013-09-30T15:43:31.347 に答える