Radici aggregate. Fino a che punto arriva la tana del coniglio

Question

Sto provando a utilizzare il modello di repository per il mio progetto corrente e attualmente sto cercando di modellare il dominio e trovare le radici aggregate.

Ho letto la regola "Elimina in cascata" che stabilisce che se non ha senso eliminare un membro quando viene eliminata la radice, non dovrebbe essere parte della radice.

userò un incidente di polizia come un eample: -

Incident (root Aggregate) - Questo potrebbe contenere indagare ufficiali, note fatte da ogni ufficiale. Potrebbe anche contenere sospetti con un elenco di date che sono state intervistate. Le riprese della CCTV sono state ottenute per l'incidente? Un registro di ogni volta che la CCTV è stata visualizzata e da chi? Sono state create copie della CCTV per prove/tribunali ecc.

Sembra che l'IncidentAggregate potrebbe diventare enorme poiché sembra che tutto si blocchi su quell'incidente.

La mia domanda è duplice, quanto dovrebbe gestire la radice aggregata e le radici all'interno delle radici sono una buona idea?

Questo potrebbe non essere un buon esempio dato che probabilmente non rimuoverei mai qualcosa come un incidente di polizia ma spero che descriva meglio la mia domanda.

Answer 1

Un aggregato di solito contiene riferimenti ad altre radici aggregate. Questi riferimenti dovrebbero essere cancellati quando l'aggregato contenente viene cancellato, ma gli aggregati a cui puntano rimarrebbero.

Per utilizzare l'analogia. Un rapporto che assumeremo fa parte di un solo aggregato di incidenti e verrebbe eliminato insieme all'aggregato. Nessun altro aggregato accederà direttamente a questi report.

Tuttavia, l'aggregato dell'incidente sarebbe riferimento aggregati che rappresentano le voci dei registri di visualizzazione di agenti e sospetti e CCTV.

Answer 2

Un aggregato è un gruppo di oggetti con lo stesso ciclo di vita.

Se si elimina un incidente, si desidera eliminare anche l'agente investigativo? No, se lo facessi, non avresti più poliziotti. L'investigatore non fa parte dell'incidente.

Delle altre cose che si elencano, sospetti, interviste, CCTV ecc. La risposta è - dipende.

Dipende dal dominio del problema. Che cosa sta facendo il tuo sistema? qual è il suo scopo? che problema sta risolvendo?

Se è solo compito è quello di monitorare una serie di inconvenienti e sospetti assumendo, interviste e CCTV sono solo nel sistema a seguito di un singolo incidente, allora sì, avendo tutti in un aggregato potrebbe essere appropriato. Se l'incidente viene cancellato, i sospetti, le interviste e le telecamere a circuito chiuso possono andare.

Se, ad esempio, i tuoi archivi di rilevamento di filmati CCTV sono raccolti da una rete di telecamere del centro città. Forse stai cercando di monitorare la loro efficacia e affidabilità. Se è così, devi trattare diversamente le riprese della CCTV. Sarebbe in un diverso aggregato con il proprio ciclo di vita. Se si elimina un incidente, si desidera mantenere il filmato CCTV per altri incidenti e metriche sul rendimento.

Ciò che è dentro e fuori un aggregato dipende dal dominio del problema. O più precisamente dipende dal modo in cui hai modellato la soluzione del dominio problematico.

Pensare al ciclo di vita.

Answer 3

"Le radici nelle radici sono una buona idea?"

Risposta breve secondo me no. Come dice Kurt, dovresti mantenere riferimenti ad altri aggregati. Per essere chiari, per riferimenti intendo l'identificazione di oggetti. Quindi, forse il vostro aggregato incidente sarebbe una proprietà come

public IEnumerable<Guid> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); } 
} 

O

public IEnumerable<OfficerReference> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); } 
} 

Per cui OfficeReference è una classe che rappresenta il valore di un'identità ufficiali (sotto il cofano sarebbe probabilmente un GUID).

Se la logica del dominio è necessaria per eseguire azioni utilizzando sia l'Incidente che i funzionari inquirenti, si astraggerà questa logica in un servizio di dominio e si utilizzerà il Reperitory IOfficer per recuperare gli aggregati ufficiali utilizzando gli ID forniti nell'aggregato dell'incidente.