Come lavorare con grandi radici aggregate?

Question

Come lavorare con grandi radici aggregate?

#1 da (16 voti)
#2 da (1 voti)

6

Sto imparando DDD eppure ho più domande che risposte.

Consideriamo un modello di una directory che contiene un numero enorme di file.
Ecco come lo vedo:

Directory è una radice di aggregazione.
Questa entità deve avere la logica di convalida del controllo dell'unicità del nome del file quando viene aggiunta o semplicemente rinominata. E l'entità file contiene la logica "SetName", che notifica la directory tramite l'evento di dominio sulle modifiche al nome.
Ma come dovrebbe funzionare Directory allora?
Non è sempre possibile caricare tutti i file in memoria. In questo caso, il repository di file ha una logica ad hoc per verificare l'univocità del nome? Suppongo sia una decisione fattibile.
Tuttavia, cosa succede se alcuni file sono già stati aggiunti o rinominati con la transazione non ancora eseguita? (nulla lo proibisce. I limiti di transazione sono stabiliti esternamente in relazione alla logica aziendale). Probabilmente il repository dovrebbe tenere in considerazione sia gli stati in memoria sia quelli persistenti (unire questi stati può essere un compito non banale.)

Quindi, quando la radice aggregata con tutti i suoi figli si adatta alla memoria, tutto va bene. E non appena non puoi materializzare tutte le entità ci sono problemi.

Mi piacerebbe sapere quali sono gli approcci per tali situazioni. Potrebbe essere non c'è alcun problema ed è solo a causa del mio fraintendimento del soggetto.

domain-driven-design

posta Pavel Voronin 16.07.2014 - 13:56

fonte

2 risposte

1

Questa non è una domanda DDD di per sé. La domanda principale qui riguarda il contesto di sincronizzazione (che è qui una radice aggregata).

Indietro sull'argomento: Directory deve bloccare su alcuni oggetti di sincronizzazione dei nomi di file ed eseguire un controllo se è consentito il nome del file dato che è O (n) nel peggiore dei casi.

risposta data 16.07.2014 - 14:06

fonte

Leggi altre domande sui tag domain-driven-design

Quali sono i vantaggi e gli svantaggi della suddivisione dei team per livello di architettura piuttosto che per prodotto? Perché è considerata una buona pratica isolare la gestione dei dati in un microservizio?

score 16 · Accepted Answer

La mia risposta è distorta con l'ottimo libro di Vaughn Vernon Implementing Domain Driven Design (da leggere)

1. Favorisci piccoli aggregati.

Se modifico il tuo dominio, modellerei Directory come aggregato e File come altro aggregato.

2. Reference aggregates by ids.

Pertanto Directory avrà una collezione di oggetti di valore FileId .

3. Utilizza le fabbriche per creare aggregati.

Per un caso semplice, un metodo factory può essere sufficiente Directory.addFile(FileName fileName) . Tuttavia, per i casi più complessi vorrei utilizzare una fabbrica di domini.
Il factory di dominio potrebbe verificare che fileName sia univoco utilizzando un FileRepository e un servizio di infrastruttura UniquefileNameValidator .

Perché modellare File come aggregato separato?

Perché Directories non è fatto di Files . a File è associato a un certo Directory . Inoltre, pensa a una directory che contiene migliaia di file. Caricando tutti questi oggetti in memoria ogni volta che viene recuperata una directory è un killer delle prestazioni.

Modella i tuoi aggregati in base ai tuoi casi d'uso. Se sai che non ci saranno mai più di 2-3 file in una directory, puoi modellarli tutti come un singolo aggregato, ma nella mia esperienza le regole di business cambiano continuamente e paga se il tuo modello è abbastanza flessibile da ospitare il modifiche.

Lettura obbligatoria Design efficace degli aggregati di Vaughn Vernon