CQRS, Come interrogare la radice aggregata usando altri campi piuttosto che GUID (ID)?

-1

Esistono molti framework CQRS e librerie di archivi di eventi.

Tutti usano GUID come ID radice aggregata.

Quell'archivio eventi mi consente solo di interrogare solo dal GUID.

Mi rendo conto che ci sono molte volte nell'ultimo progetto (DDD + CRUD) ho bisogno di interrogare la radice aggregata usando altri campi piuttosto che GUID.

A volte usa i campi coppia.

Come risolvere questo problema?

Devo interrogare il modello di lettura all'interno del gestore di comandi?

Oppure ho bisogno di costruire un altro repository per mappare le proprietà su GUID?

O devo risolvere questo problema riprogettando i modelli di dominio e interrogando le cose per ottenere GUID prima di inserire il comando? Ho chiesto è qui

    
posta b.ben 20.06.2018 - 04:19
fonte

1 risposta

3

CQRS / ES è un'architettura difficile in molti aspetti e ne hai trovato uno.

Prima di tutto, dal momento che stai memorizzando eventi è molto difficile interrogare un'entità in base ai suoi dati poiché non hai in realtà lo stato dell'entità archiviato da nessuna parte, solo gli eventi che genereranno tale stato. Non funzionerà come una normale memoria di stato in cui puoi entrare nel tuo record e interrogare una persona dal suo nome, per esempio.

Quindi, per il lato di comando (il lato ES) della tua equazione, dovresti essere in grado di recuperare in modo affidabile un'intera entità tramite il suo ID e quindi riprodurre gli eventi per ricostruire il suo stato finale.

Ora, naturalmente, ci sono scenari aziendali in cui dovrai trovare una persona dal suo nome. Quando ciò accade, il modo più semplice per procedere è semplicemente interrogare il modello letto e quindi procedere a recuperare l'ID per ottenere l'entità comando da esso. Si noti che il lato di lettura è soggetto a un ritardo di propagazione dal lato di comando. Ciò significa che è solo alla fine coerente. Una volta che un comando viene attivato ed elaborato dal lato di comando, ci sarà un periodo di tempo casuale in cui il lato di lettura non rifletterà questa ultima modifica, quindi il tuo codice deve essere preparato per questo.

Tuttavia, dovresti davvero provare a comunicare il tuo livello di applicazione in termini di ID entità per evitare questo passaggio extra il più possibile e non dovrebbe essere così difficile.

Immagina che alcuni clienti stiano leggendo i dati relativi a una delle tue entità. Se ciò accade, quel cliente probabilmente già detiene le informazioni ID di quell'entità data. Quindi, se vuole inviare un comando a tale entità, dovrebbe essere in grado di attivarlo in base al suo ID e non su altri dati basati sullo stato.

    
risposta data 22.06.2018 - 04:14
fonte

Leggi altre domande sui tag