Aggiornamento di oggetti figlio profondi su una radice aggregata

1

Come devo eseguire aggiornamenti su figli nidificati di una radice aggregata?

Dovrei trovare l'oggetto figlio attraversando le associazioni ed eseguire direttamente l'aggiornamento su di esso, o dovrei aggiungere un metodo alla radice di aggregazione che si occupa di esso?

Un esempio

Sto modellando un vecchio progetto nella nostra azienda che è un sistema che utilizziamo per eseguire ricerche di clienti contro un elenco di persone sospette:

Il modello

  • Eseguiamo un Batch Search ogni notte
  • Il Batch Search contiene un elenco di Searches per esso.
  • Ogni Search contiene un elenco di Matches ed è associato a un Customer

Il processo

  • Controlliamo ogni Match e lo contrassegno come confermato se si tratta di una corrispondenza confermata.
  • Selezioniamo anche una casella di controllo per ogni Search se tutto è Matches dove ispezionato

L'avvertenza

Anche un Search può essere eseguito standalone, come in - non fa parte di Batch Search . In tal caso, Search diventa naturalmente la radice di aggregazione.

Domanda

How should I be performing the update operations on the child items? The blue book states that all updates to children must go through the Aggregate Root.

Ci sono 2 modi per eseguire questo aggiornamento:

Opzione 1

Attraversa il grafico e trova l'oggetto figlio ed esegui direttamente l'operazione su di esso.

batchSearch = batchSearchRepo.find(1);
search = batchSearch.findSearch(5);
match = search.getMatch(3);
match.markConfirmed();
batchSearchRepo.save(batchSearch);

Opzione 2

Aggiungi un metodo su Aggregate Root

batchSearch = batchSearchRepo.find(1);
search = batchSearch.markSearchMatchAsConfirmed(5, 3);
batchSearchRepo.save(batchSearch);

Quale dei 2 metodi di aggiornamento è più appropriato e perché?

    
posta Nik Kyriakides 28.07.2017 - 14:10
fonte

1 risposta

2

Esistono root aggregati per proteggere i dati al loro interno. Se si strappano le strutture interne di radice aggregate e si eseguono le operazioni direttamente sui componenti interni senza incorporare la radice aggregata, la radice aggregata non può più validare l'operazione è valida.

Nel DDD la seconda opzione non è solo più appropriata, è l'unica strada corretta da seguire (come indicato nella citazione che hai postato).

Quando incontri comunque il nesting che hai, puoi anche farti una domanda se il tuo design è corretto al 100%.

  1. Non sono forse alcuni dei componenti interni di BatchSearch di aggregare le radici da soli?
  2. Non potrebbe forse Search esistere al di fuori del limite di BatchSearch ?
  3. L'influenza su Search influisce su BatchSearch ?

Se hai risposto si alle domande 1 e 2 e no alla terza domanda, hai già eliminato un intero livello di nidificazione e ora puoi accedere a Search direttamente come radice aggregata separata. Con questo in mente, potresti forse fare lo stesso per Match ?

    
risposta data 28.07.2017 - 14:25
fonte

Leggi altre domande sui tag