Perché limitare comandi ed eventi a un aggregato? CQRS + ES + DDD

Question

Si prega di spiegare perché la modifica di molti aggregati allo stesso tempo è una cattiva idea quando si eseguono CQRS, ES e DDD. C'è qualche situazione in cui potrebbe ancora essere ok?

Prendi ad esempio un comando come PurgeAllCompletedTodos. Voglio che questo comando porti a un evento che aggiorna lo stato di ogni aggregato Todo completato impostando IsActive su false.

Perché non va bene?

Una ragione mi veniva in mente:

Quando si aggiorna lo stato del dominio è probabilmente un bene per limitare l'operazione a una parte ben definita di tutto lo Stato in modo che solo questa parte ha bisogno di essere bloccata in scrittura durante l'aggiornamento. Ciò consentirebbe a molte scritture su diversi aggregati in parallelo che potrebbero migliorare le prestazioni in alcuni scenari estremamente pesanti.

Answer 1

La risposta della domanda si trova nel significato di "aggregato".

Come prima cosa direi che non stai modificando gli aggregati "n", ma stai modificando le entità "n".

Un aggregato contiene più-che-un'entità ed è solo una transazione concetto , l'aggregato (pattern) viene utilizzato quando è necessario modificare lo stato di più di un un'entità nell'applicazione transazionale (tutto sono modificati o nessuno).

Ora, perché si dovrebbe modificare più di un aggregato con un comando?

Se ritieni che ciò sia necessario, prima di fare qualsiasi altra cosa controlla i tuoi limiti aggregati per vedere se è possibile modificarlo per rimuovere il comando 1 necessario -> 'n' aggregato.

Un aggregato può contiene un sacco di enti dello stesso tipo, quindi per il vostro comando PurgeAllCompletedTodos, si potrebbe anche pensare a espandere il limite di transazione da un unico Todo ad un aggregato UserTodosAggregate che contiene tutte le user todos, e lascia che gestisca tutti i comandi per i todos di un singolo utente.
In questo modo è possibile modificare tutte le situazioni di un utente in una singola transazione.

Se questo non risolve il problema perché, diciamo che è necessario eliminare tutti i todos completati di ciascun utente nell'applicazione, sarà comunque necessario inviare un comando a aggregati 'n', il limite aggregato non Aiuta, quindi, possiamo pensare di avere un AllApplicationTodosAggregate che gestisce il comando.
Probabilmente questa non è la soluzione migliore, perché come hai detto che il comando bloccherebbe TUTTI i todos dell'applicazione, ma, controlla sempre se può essere un buon compromesso (questa parte del blocco è spiegata molto bene in sia Blue Book che Red Book of DDD).

Cosa succede se ho bisogno di modificare alcune entità e non posso averle in un unico aggregato?

Con il precedente, un comando che modifica più di un aggregato è danneggiato a causa delle transazioni. Cosa succede se si modifica 3 aggregato, il primo è buono, e quindi il server è spento?

In questo caso, ciò che si sta facendo è avere una singola modifica che deve essere gestita per evitare l'incoerenza del sistema. L'operazione può essere eseguita utilizzando un gestore di processi, in cui le responsabilità modificano tutti gli aggregati inviando loro il comando corretto e gestendo i guasti se si verificano.

Un aggregato ancora ricevere il proprio comando, ma il gestore del processo ha il compito di inviare loro in un modo che conosce (uno alla volta, tutti in parallelo, 5 per volta, che cosa-do-you-want)
Quindi puoi avere una strategia per gestire l'errore tra due transazioni e prendere una decisione del tipo: "se qualcosa fallisce, ripristina tutte le modifiche fatte fino ad ora" (inviando un comando di rollback a ogni aggregato), o "se un'operazione fallisce ripetere 3 volte ogni 30 minuti e se non funziona non funziona "rollback", "se qualcosa fallisce crea una notifica per l'amministratore di sistema".

(dispiace per il lungo post, almeno spero che aiuta)