Radice aggregata e dilemma del repository

Devi impostare le regole da solo prima di modellare. Ecco alcuni suggerimenti

• Una squadra può esistere senza una lega. In quale altro modo sarebbero in grado di giocare partite fuori dal campionato?
• I giocatori possono cambiare squadra.
• I giocatori non spariscono improvvisamente se una squadra viene chiusa.

Dipende tutto da come funziona la tua applicazione. Se hai bisogno di fare riferimento a un aggregato al di fuori della radice (senza la radice), di solito significa che quell'aggregato dovrebbe essere una radice per.

Aggregato non significa "non può esistere senza". Significa che i due sono logicamente legati insieme e root gestisce l'accesso alle entità all'interno dell'aggregato. Nel tuo caso, non penso che League e Team siano aggregati. Lo stesso con League and Player.

Penso che stai pensando a complesso. Quello che hai qui sono tutte entità correlate. Questi sono tutti nello stesso livello e hanno tutte la stessa intenzione: gestione dei dati.

Pensa all'utilizzo del Pattern Supertype Layer di Martin Fowler. Dice:

It's not uncommon for all the objects in a layer to have methods you don't want to have duplicated throughout the system. You can move all of this behavior into a common Layer Supertype.

Dovresti avere ad esempio una classe EntityBase. Una classe astratta che gestisce tutte le cose comuni come ID, Validazione, confronto.

Ciascuno dei tuoi articoli è entità e dovrebbe avere un proprio repository. Se non si desidera che un repository specificato abbia la posibilità per le azioni di scrittura, è possibile suddividere l'interfaccia IRepository in due parti: IReadOnlyRepository e IRepository.

Per il tuo esempio: Puoi avere più campionati, un campionato ha più squadre e una squadra può avere solo 1 campionato?!?. Ogni squadra ha più giocatori e possono far parte di una sola squadra. Tuttavia. Tutto dipende dalle informazioni che si desidera riutilizzare. Ma per un buon DB Design dovresti avere ciascuna di queste entità come propri aggregati.