Nuovo ID entità nell'evento di dominio

Question

Sto costruendo un'applicazione con un modello di dominio utilizzando CQRS e concetti di eventi di dominio (ma nessun evento di approvvigionamento, solo semplice vecchio SQL). Non c'è stato nessun problema con gli eventi di tipo SomethingChanged. Poi sono rimasto bloccato nell'implementare eventi SomethingCreated.

Quando creo una qualche entità, che è associata a una tabella con chiave primaria identità poi non si conosce l'ID fino a che viene mantenuto l'entità. L'entità è ignoranza della persistenza, quindi quando pubblichi un evento dall'interno dell'entità, Id non è noto - è magicamente impostato solo dopo aver chiamato context.SaveChanges(). Quindi come/dove/quando posso inserire l'ID nei dati dell'evento?

pensavo:

• Compreso il riferimento all'entità nell'evento. Ciò funzionerebbe all'interno del dominio ma non necessariamente in un ambiente distribuito con più sistemi autonomi che comunicano per eventi/messaggi.
• Sovrascrivere SaveChanges() per aggiornare in qualche modo gli eventi accodati per la pubblicazione. Ma gli eventi devono essere immutabili, quindi questo sembra molto sporco.
• Eliminazione dei campi identità e utilizzo dei GUID generati nel costruttore entità. Questo potrebbe essere il più semplice, ma potrebbe colpire le prestazioni e rendere più difficili altre cose, come il debug o l'interrogazione (where id = 'B85E62C3-DC56-40C0-852A-49F759AC68FB', n. MIN, MAX ecc.). Questo è quello che vedo in molte applicazioni di esempio.
• Approccio ibrido: non utilizzare l'identità e utilizzarla principalmente per chiavi esterne e join più veloci, ma utilizzare GUID come identificativo univoco mediante il quale estrarre le entità dal repository nell'applicazione.

Answer 1

Personalmente mi piacciono i GUID per identificatori univoci, specialmente in ambienti distribuiti multiutente, dove gli ID numerici causano problemi. Pertanto, non utilizzo mai colonne/proprietà di identità generate dal database e questo problema scompare.

mancanza di ciò, dato che si sta seguendo CQRS, si hanno indubbiamente un CreateSomethingCommand e corrispondente CreateSomethingCommandHandler che esegue effettivamente i punti necessari per creare la nuova istanza e persistono il nuovo oggetto utilizzando il repository (tramite context.SaveChanges). Alzerò qui l'evento SomethingCreated piuttosto che nell'oggetto dominio stesso.

Per uno, questo risolve il problema, perché il gestore di comandi può attendere che l'operazione di database per completare, tirare fuori il valore di identità, aggiornare l'oggetto poi passare l'identità alla manifestazione. Ma, cosa più importante, affronta anche la difficile domanda su esattamente quando l'oggetto 'creato'?

Crescere un evento dominio nel costruttore è cattiva pratica come costruttori dovrebbero essere magra e semplicemente eseguire l'inizializzazione. Inoltre, nel tuo modello, l'oggetto non viene realmente creato finché non viene assegnato un ID. Ciò significa che sono necessari ulteriori passaggi di inizializzazione dopo l'esecuzione del costruttore. Se hai più di un passo, fai rispettare l'ordine di esecuzione (un altro anti-pattern) o metti un segno di spunta in ognuno per riconoscere quando sono tutti fatti (ooh, puzzolenti)? Spero che tu possa vedere come questo può rapidamente sfuggire di mano.

Quindi, la mia raccomandazione è di sollevare l'evento dal gestore di comandi. (Nota: anche se si passa a identificatori GUID, mi piacerebbe seguire questo approccio, perché non si dovrebbe mai alzare gli eventi da costruttori.)