Cosa fare quando un aggregato riceve un brutto evento?

What is usually done when an aggregate is asked to apply an "impossible" event to its state?

Risposta breve? rapporto sulle eccezioni.

Risposta più lunga: supponendo che il modello di dominio sia l'autorità per l'aggregato, non esiste in realtà un tale "stato impossibile". Ci sono stati non raggiungibili - stati che non hanno transizioni in entrata - ma non ci sono stati realmente impossibili.

Nella maggior parte dei domini maturi, esistono già protocolli per correggere errori di immissione dei dati; in contabilità, ad esempio, normalmente aggiungerai nuovi eventi nello stream che in primo luogo invertiranno gli effetti dell'errore e correggeranno l'errore.

Nei domini meno maturi, potresti inventare quei protocolli mentre procedi.

Greg Young ha offerto alcuni consigli interessanti: stop over engineering . Automatizza i percorsi felici che sono ben compresi e rimetti i problemi più difficili agli esseri umani.

Ergo: segnalazioni di eccezioni: quando il gioco diventa strano, lascia che siano gli esseri umani a ordinarlo.

So, throw, fail all commands that rely on this aggregate, and page people like crazy?

Probabilmente. In molti casi, la cosa importante da comprendere è che gli stati che sono fuori dal percorso felice potrebbero essere ancora stati raggiungibili nel dominio . Potrebbe essere che le funzionalità complete o limitate siano ancora disponibili mentre l'entità si trova sul percorso del protocollo di recupero.

Ad esempio, prendi in considerazione una mappa dei posti per un aereo. Lo stesso posto non dovrebbe essere assegnato a due passeggeri diversi. Ma gli agenti di gate dispongono di protocolli che possono utilizzare per risolvere la situazione e non vi è alcun motivo particolare per impedire l'assegnazione di altri posti sul volo mentre il conflitto esiste.

Il problema è che lo chiami un evento. Gli eventi sono resoconti di ciò che è successo. Non possono fallire perché sono finiti e finiti. Poiché questo non è ancora successo, e può ancora fallire, è un comando.

Se qualcosa è abbastanza bello da raccontarti di un evento puoi affrontarlo come preferisci, ma a nient'altro importa quello che fai. Se qualcosa ti dà un comando, faresti meglio a farlo o spiegare perché no.

La convalida è necessaria in entrambi i casi se c'è la possibilità di ottenere cose che non sai come gestire. La differenza è: quando una convalida di eventi fallisce, a nient'altro importa. È un tuo problema.

So, should I really pretend there isn't any chance that this event will come? Should I just pretend/cast that I know that if this event arrived, the state is such that this event can be meaningfully applied to?

Pensando un po 'di più a questo con un po' di caffeina in più, molto dipende da cosa succede nel ruolo di questo aggregato. Se il punto dell'aggregato è semplicemente registrare gli eventi nel modo in cui si sono verificati e riprodurli come un record di transazione, probabilmente dovresti accettare qualsiasi cosa ricevuta. Se devi anche inviare eventi immediatamente o se qualche altra parte del sistema è responsabile della convalida, è in discussione.

Tuttavia, se questi eventi "impossibili" causano l'ingresso di questo stato in uno stato non valido, questa è la cosa peggiore che si possa fare. Mi sono imbattuto in questo pensiero molte volte ed è sempre un errore. Di solito mi imbatto in questo tipo di errore durante la risoluzione di problemi brutti come la corruzione dei dati. Se pensi che qualcosa non accadrà mai, dovresti sempre aggiungere una sorta di pulsante di panico che si attiva se lo fa. Ci sono due ragioni di base per questo:

1. Quando hai un allarme (affidabile) per qualcosa che non credi possa accadere, la mancanza di quegli allarmi è la prova che la tua asserzione è corretta. Se ignori qualsiasi evento di questo tipo, non hai alcuna prova della tua ipotesi in ogni caso.

2. Come un uomo saggio una volta disse: "Succede la merda". Solo perché non c'è motivo per cui il sistema dovrebbe consentire a chiunque di aggiungere un oggetto dopo il pagamento, ciò non significa che non possa o non possa accadere. Questa è un'altra parte del sistema che non puoi controllare in questa parte. La probabilità che il sistema che genera questi eventi sia priva di difetti e che rimanga sempre tale è esattamente pari allo 0%.

Per quanto riguarda il 2, c'è una buona probabilità che qualche attore malevolo provi a causare una serie di eventi del genere. Ad esempio, esiste un chiaro incentivo finanziario sul motivo per cui qualcuno potrebbe acquistare una pen drive e quindi tentare di aggiungere un laptop all'ordine dopo il pagamento. Se qualcuno ci riuscisse, pensa a quale sarà la tua spiegazione per ignorarlo. Pensi che "ho pensato che potesse / non sarebbe mai successo" ti sembrerebbe un buon esempio?