StackOverflow を何週間も読んでいますが、DDD Aggregate Root の選択が正しいかどうかまだ判断できませんでした。簡単に言えば、エンティティは次のとおりです。それはフットボール/サッカーのドメインについてです:
リーグ、チーム、試合
各チームは、試合を行うことで 1 つまたは複数のリーグに参加できます(例: イングランド プレミア リーグ、UEFA チャンピオンズ リーグ)。各チームには、特定のリーグでホームマッチとアウェイマッチがあります。各試合にはLeague、HomeTeam、およびAwayTeamがあります。
各リーグには多くの試合があります。
2 つのリポジトリが必要だと思います。特定の期間、特定のリーグのすべての試合を取得できる LeagueRepository です。このリポジトリを通じて、試合のラウンドが行われたときにデータベースを自動的に更新し、それに応じて結果を記録します。
また、TeamRepository も必要です。これにより、特定のチームのさまざまな期間のさまざまなリーグのすべての試合を取得できます。これは統計上の目的のためです。つまり、過去 10 年間の英国プレミア リーグのリバプール ホーム マッチをすべて教えてください。ええ、あなたは正しいと思います-それは賭けのチャンスとオッズ計算についてです:)
簡単に言えば、私のドメインはフットボール/サッカーの世界です。スポーツをフォローしている方は、これらの詳細と、リーグ、チーム、試合とは何かを知っています。
リーグとチームという 2 つの別個の集計ルートを使用しても問題ありませんか。それらのいずれかを介して特定の一致に到達できます。これは DDD 設計で問題ありませんか?
または、 Sportという新しいエンティティを導入して、それを唯一の集約ルートにする必要があります。その場合、スポーツには多くのリーグと多くのチームがあります。
私はEFコードファーストアプローチを使用しており、リポジトリと集約ルートを特定しようとしています。このデータベースを設計する場合、リーグ、チーム、試合の 3 つのエンティティをどのように構成しますか。もちろん、ここでは単純化しすぎています。
ご意見やご感想をお待ちしております。
前もって感謝します。