What is the best way of preventing of events from being handled more than once?
Il modo migliore: scrivi il tuo modello di dominio in modo tale che la gestione al massimo una volta sia incorporata nella logica aziendale.
Marc de Graauw, da Nessuno ha bisogno di messaggi affidabili :
Stating that it is important on the business level that every message is received exactly once, like it is in order processing, means that every message constitutes a unique business transaction.... if every message is a unique business transaction, clearly there must be a unique id on the business level.... if we need such a unique token on the business level, the business level should assert it's uniqueness. Uniqueness on the business level should not be dependent on the transient uniqueness on the message level, but must be a persistent feature of the business message, and business semantics must guarantee it.
Ma questo non è il tipo di esempio che stai considerando;
One process is to send an email to the customer, assume there is a requirement that the customer MUST be sent an email.
In una situazione in cui DEVE; Normalmente cercherò almeno una volta la gestione dell'evento. Il processo tiene traccia di entrambe le e-mail richieste e che sono state riconosciute.
Ad esempio, il processo che sottoscrive a OrderCreated , EmailSent e EmailTimedOut . Su "ordine creato", inviamo un comando per inviare l'email e un altro per pubblicare l'evento di timeout. Dopo aver ricevuto il timeout, controlliamo se è apparso il messaggio EmailSent; in caso contrario, rispediamo .
Are there any better ways to handle problems like these?
Rivedere in dettaglio il costo per il business delle diverse modalità di errore. Se DEVI inviare l'e-mail, allora hai bisogno di sapere che l'hai fatto. Se l'ack può perdersi, allora è necessario inviare nuovamente: qual è il costo per l'attività di invio di tale e-mail più di una volta? Non iscriversi alla perfezione costosa quando il guasto è raro e a basso costo.
I feel like this sort of thing would be a common problem but I can't find a robust solution.
Jonathon Oliver: Messaggi: almeno una volta la consegna
One of the primary reasons, if not the primary reason, that messaging systems offer at-least-once delivery rather than exactly-once delivery is that we run into limitations as expressed in the CAP theorem—all “nodes” cannot possibly have a globally consistent snapshot and be available and partition tolerant. There is no unfailing “global brain”.
Vedi anche: link