Abbiamo parlato di permanent errors e transient errors, c’è un’ultima categoria di errori che dobbiamo prendere in considerazione: gli errori di business.
Gli errori di business non esistono
Supponiamo uno scenario di questo genere:
Il servizio X invia il comando CreaUtente con annessi tutti i dettagli, il servizio Y prende in carico il messaggio e la validazione delle regole di business fallisce perché un utente con la stessa mail esiste già.
In un caso come questo, e potete immaginarne infiniti altri:
- Ha senso riprovare il messaggio come faremmo con un transient error?
- Ha senso inoltrare il messaggio ad una coda di errore dove un membro del team operation non ha nessuna possibilità di farci nulla?
Un messaggio come quello dell’esempio, se genera un errore di business deve essere seguito da uno o più eventi, o messaggi di risposta, che dettagliano quello che è successo. Quindi il servizio Y può ad esempio pubblicare un evento CreazioneUtenteFallita con i dettagli del problema.
È quindi importante in scenari come questo andare dal business e chiedere: cosa deve succedere se la mail è duplicata? di certo non è un’eccezione come se il database non fosse disponibile. È tutto li :-)