In genere, dovresti gestire questo tipo di cose nell'applicazione, piuttosto che nel dominio. Ad esempio, un limitatore di velocità per limitare il numero di modifiche per BlogPost, forse un altro sul comando di modifica stesso. Questo genere di cose si presenta nella sicurezza dell'autenticazione, quindi potresti guardare lì.
Un secondo approccio sarebbe quello di trattare i voti su o giù come eventi, piuttosto che come comandi. Si tratta di eventi esterni a cui l'applicazione si iscrive, proprio come se stessero ascoltando eventi emessi da un modello di dominio diverso. Un responsabile di processo downstream si iscrive agli eventi e invia i comandi al modello in risposta.
Il vantaggio qui è che ha senso trattare gli eventi come un lotto; piuttosto che passare attraverso ogni evento che vedi, puoi filtrare tutti gli eventi che si annullano prima di passarli per l'elaborazione. Puoi anche usare la limitazione qui (di nuovo, questi non sono gli eventi del tuo modello, quindi non devi preoccuparti di re-idratare lo stato da loro, puoi solo usare i tuoi eventi per ricostruire lo stato).
Se quelli non funzionano per le tue circostanze, potresti anche considerare di caricare il tuo stato dalle istantanee (hai ancora la cronologia degli eventi enormemente lunga, ma non importa perché quegli eventi sono stati compressi dietro lo snapshot recente).
Un'altra alternativa è semplicemente riparare il flusso di eventi; elidere gli eventi generati dall'attacco, generare nuovi numeri di sequenza per il resto, sostituire. Se il problema è raro e poco costoso da risolvere, è perfettamente ragionevole per l'azienda decidere che soluzioni complicate per prevenire il problema non sono una priorità.