Quindi ho radice Aggregate che ha alcune sub-entità con alcuni oggetti di sotto-valore (design classico DDD). Volevo anche utilizzare il sourcing di eventi nella progettazione di aggregati. Nel livello AppService ricevo il comando, lo decodifico e il metodo di chiamata sull'aggregato (ho capito che questa è una pratica comune in ES):
public class AgRoot {
private Int id;
private List<SomeValueObj> objs;
public void doSmthn(SomeValueObj arg){
//check if arg (some logic) can be applied to this aggregate
for(SomeValueObj o : objs){
if(!o.canBeUpdatedWith(arg)){ throw Exception(); }
}
GenEvent event = constructeventfrom(arg);
this.causes(event);
}
public void when(GenEvent event){
//set all fields in this aggregate
for(SomeValueObj o : event.objs){
o.applyChangeActually(o)
}
}
}
Ora, la mia domanda è: perché qui dobbiamo verificare se questo argomento può essere applicato, quindi creare un evento e solo allora applichiamo effettivamente le modifiche (scriviamo fondamentalmente i valori dei dati sull'oggetto). Sembra che stiamo separando la parte in cui controlliamo se il contenuto di arg è valido e può essere applicato da una parte in cui vengono effettivamente copiati valori da arg per aggiornare lo stato dell'oggetto. Nel DDD standard senza ES, passerei solo arg giù il grafico degli oggetti agli oggetti lista objs: essi gestivano tutti i controlli e gli aggiornamenti da soli.
Ho frainteso il concetto di ES?
Aggiorna
Giusto per chiarire un po 'di più: se non devo solo fare dei semplici controlli come se arg! = null (che è la cosa normale che hanno tutti gli esempi ES) - ad es. prima di aggiornare ogni SomeValueObj nell'elenco obj, devo eseguire costosi calcoli e molta logica in ognuno degli oggetti objs - e possibilmente aggiornare parzialmente questi oggetti con nuovi dati per procedere con i calcoli - sembra che quando la funzione (GenEvent event) teoricamente fai ancora la stessa cosa ?? Mi sembra il problema dell'uovo di gallina.
Questa sembra la cosa di cui sto parlando Strutture complesse di aggregazione