Si è confuso durante la progettazione degli aggregati

1

Sto progettando un'applicazione, che memorizzerà le statistiche sportive, le mostrerò in diagrammi diversi e faremo ancora poche operazioni su di esse. Consenti all'utente di eseguire alcune bozze finte, ecc.

Ho scelto di creare prima un dominio, quindi creare un database tramite l'approccio code-pugno. Quindi ho le mie entità:
- Player (nome, teamID, elenco delle statistiche)
- Squadra (nome, elenco dei giocatori)
- Statistiche (beginDate, endDate, playerId, < ... statistiche diverse in colonne separate > ...........)

Come dovrei dividerli in aggregati? So che Player è un aggregato. So che l'elenco dovrebbe essere in Player aggregato. Ma per quanto riguarda il Team ? La parte del team di Player è aggregata o separata?

Sono confuso, perché il giocatore deve sicuramente avere una chiave esterna per la squadra. Ma la squadra ha perfettamente senso senza un giocatore (non come Stats, che senza un giocatore non ha alcun senso - è per questo che fanno parte dell'aggregazione di Player). Potrei mostrare solo le statistiche per i team.

La squadra dovrebbe essere un aggregato separato?

EDIT: Ecco come appare il mio dominio:

public class Stats
{
    // Stats...
}

public class Player
{
    public Team Team { get; private set; }
    public List<Stats> Stats { get; private set; }
}

public class Team
{
    public string Name { get; private set; }
    public string FullName { get; private set; }
}
    
posta Sara 30.05.2016 - 22:23
fonte

1 risposta

2

L'importante domanda da porre, quando si progettano gli aggregati, è come cambia il dato?

Il team per essere un aggregato implica che abbia qualche stato, e anche dopo che lo stato cambia, è sempre la stessa squadra. (per esempio, affinché il team sia un aggregato, deve essere un'entità, non solo un tipo di valore).

Quindi nel tuo modello, le squadre cambiano in qualche modo interessante? Con quale intendo, in un modo che il tuo modello si preoccupa? O sono semplicemente un attributo di un giocatore.

Se i team sono un'entità e ti preoccupi veramente delle cose che la squadra fa (rilasciando giocatori, acquisendo giocatori e così via), allora la squadra dovrebbe probabilmente essere un aggregato, e il suo stato include una raccolta di playerIds. (Nota, in questo modello, probabilmente non includeresti un TeamId all'interno del gruppo di giocatori).

D'altra parte, se i team sono solo una proprietà, possono essere un tipo di valore all'interno dell'aggregazione del giocatore.

Detto questo, ho già giocato in domini simili - ecco cosa faccio.

Il giocatore è un aggregato; ma lo stato di un giocatore è principalmente informazione biografica. Quando si scopre che alcuni giocatori hanno utilizzato un certificato di nascita falsa, l'aggregazione del giocatore viene aggiornata, ma ciò non cambia nessuna delle relazioni con il resto del modello.

Il team è un aggregato. Attualmente sto usando la squadra come una collezione di giocatori, ma non è giusto per quello che sto facendo. Nel mio mondo, la relazione tra squadra e giocatore ha una certa dipendenza dal tempo. Quindi c'è qualche entità come "Contratto", che definisce la relazione tra un giocatore e una squadra per un certo periodo di tempo (data di inizio, data di fine). Il contratto è un'entità nel mio modello, perché la data di fine del contratto "corrente" dei giocatori non è fissa.

Il GameLog nel mio modello è dove appaiono le statistiche. Non devo preoccuparmi di specifici eventi di gioco; Semplicemente aggrego le prestazioni di un giocatore alla fine di un gioco per creare una voce di registro.

Quindi per ottenere le statistiche della squadra, ho bisogno di guardare i contratti per capire quando ogni giocatore stava giocando per loro, e usare quelle informazioni per trovare i registri di gioco appropriati da tirare, e poi arrotolare il lotto.

Inoltre: c'è un po 'di attenzione, perché gli eventi sportivi nel mondo reale non sono limitati dal tuo modello di dominio. Non vuoi rifiutare i dati del "mondo reale" solo perché il tuo modello dice che non avrebbe dovuto succedere!

Non semplificare eccessivamente - parte del punto di progettazione basata sul dominio è ascoltare attentamente ciò che la lingua onnipresente ti sta dicendo, e assicurarti di modellare accuratamente questi concetti.

    
risposta data 31.05.2016 - 00:46
fonte