aggregati CQRS

Question

Sono nuovo nel mondo CQRS/ES e ho una domanda. Sto lavorando a un'applicazione web di fatturazione che utilizza il sourcing di eventi e CQRS.

La mia domanda è questa: a mio avviso, un nuovo comando che entra nel sistema (diciamo ChangeLineItemPrice) deve passare attraverso il modello di dominio in modo che possa essere convalidato come un comando legale (ad esempio, per verificare se questo elemento pubblicitario esiste realmente, il prezzo non viola nessuna regola aziendale, ecc.). Se tutto va bene (il comando non viene rifiutato), l'evento appropriato viene creato e archiviato (ad esempio LineItemPriceChanged)

La cosa che non ho ottenuto è come mantenere questo aggregato in memoria per cominciare, prima di provare ad applicare il comando. Se ho un milione di fatture nel sistema, dovrei riprodurre l'intera cronologia ogni volta che voglio applicare un comando? Salvare sempre l'evento senza alcuna convalida e faccio le convalide quando costruisco i modelli/le proiezioni della vista?

Se ho frainteso qualsiasi parte del processo, gradirei il vostro feedback.

Grazie per il vostro aiuto!

Answer 1

Non siete soli, questo è un malinteso comune. Lasciatemi rispondere prima alla parte di convalida:

Esistono due tipi di convalida che si verificano in questo tipo di sistema. Il primo è il tipo in cui si cercano indirizzi email validi, solo valori numerici o campi obbligatori. Questo tipo viene eseguito prima che il comando venga emesso. Un comando che contiene questi tipi di problemi non dovrebbe essere sollevato come comandi (per cintura e parentesi graffe è possibile controllare sul lato del dominio, ma questo non è un problema di dominio e si sta meglio impedendo solo questo scenario).

Il prossimo tipo di convalida è quando è un problema di dominio. Potrebbe essere il tipo di cosa che hai menzionato in cui controlli i prezzi all'interno di una serie di parametri specificati. Questo è un concetto di dominio che gli uomini d'affari comprenderanno, faranno e saranno in grado di articolare.

La fase successiva prevede che il dominio applichi la modifica dello stato e aumenti gli eventi associati. Questi vengono poi mantenuti e in caso di successo, pubblicati per il resto dell'app.

Tutto questo può essere fatto con l'aggregato in memoria. Le azioni sono coordinate con un servizio di dominio che gestisce il comando. Carica l'aggregato, applica tutto è gli eventi passati (o carica uno snapshot) quindi emette il comando. In caso di successo del comando richiede tutti i nuovi eventi non salvati e tenta di persisterli. In caso di successo pubblica i nuovi eventi.

Come si vede, carica solo gli eventi per quell'aggregato specifico. Anche con molti eventi questo processo è velocissimo. Se le prestazioni sono un problema, ci sono strategie come mantenere gli aggregati in memoria o le istantanee che è possibile applicare.

Al tuo ultimo punto sulla convalida degli eventi. Poiché possono essere generati solo dal tuo aggregato, sono affidabili.

Se si desidera maggiori dettagli, consultare la mia panoramica di CQRS e ES here. E dai un'occhiata al mio post su come creare radici aggregate here.

Buona fortuna - spero che aiutano!

Answer 2

È giusto che tu debba ripetere l'evento per "reidratare" l'aggregato del dominio. Ma non è necessario riprodurre tutti gli eventi per tutte le fatture.Se memorizzi l'id entità dell'aggregato di root negli eventi, puoi semplicemente selezionare e riprodurre gli eventi con l'id pertinente.

Quindi, come si trova l'ID radice aggregato pertinente? Uno dei repository di lettura dovrebbe contenere le informazioni rilevanti per ottenere l'id, in base a una serie di criteri di ricerca.