Event sourcing o modello tradizionale: come decidere cosa conservare come fonte di verità

Scegliere come rendere persistenti i dati di un’applicazione non è soltanto una decisione di archiviazione. Determina che cosa si può ricostruire, come si spiegano le modifiche e quanto lavoro serve per mantenere il sistema. L’event sourcing conserva una sequenza di eventi come fonte di verità; un modello tradizionale, invece, memorizza di norma lo stato corrente e, se necessario, una cronologia supplementare.

Nessuna delle due opzioni è sempre superiore. La domanda utile è quando la cronologia completa e la possibilità di ricostruire lo stato offrono un valore sufficiente a giustificare un’architettura più impegnativa. Questa guida propone criteri pratici per decidere, riconoscere alternative più semplici e iniziare con un ambito circoscritto.

Che cosa significa event sourcing e cosa cambia rispetto al modello tradizionale

Con l’event sourcing, l’applicazione registra fatti di business già avvenuti, come OrdineCreato, PagamentoConfermato o IndirizzoAggiornato. Lo stato attuale si ottiene applicando gli eventi nell’ordine in cui si sono verificati. Anziché sovrascrivere una riga con l’ultimo valore, si conserva una sequenza che descrive l’evoluzione dell’entità.

In un modello tradizionale, il database contiene normalmente la versione corrente: per esempio, lo stato attuale di un ordine e il suo importo. Un aggiornamento sostituisce i valori precedenti. Se serve sapere chi ha modificato un dato, quando o quale fosse il valore precedente, si può aggiungere un registro di audit o una cronologia specifica.

La differenza decisiva non è che un approccio abbia una cronologia e l’altro no. Riguarda quale registrazione costituisce l’autorità. Nell’event sourcing, gli eventi sono la fonte di verità e le viste attuali derivano da essi. In un modello tradizionale, di solito è lo stato persistito a fare da autorità; la cronologia, quando esiste, svolge una funzione aggiuntiva.

Parti dal problema, non dall’architettura

Prima di scegliere, definisci quale domanda di business oggi non riesci a risolvere. «Vogliamo più tracciabilità» è troppo generico; «dobbiamo ricostruire quali decisioni hanno determinato il saldo di un conto in una certa data» descrive un’esigenza verificabile. Questa precisione permette di confrontare le soluzioni senza adottare un’architettura solo perché è tecnicamente interessante.

• Cronologia: occorre consultare le modifiche precedenti, ma non necessariamente ricostruire l’intero stato. Può bastare un registro di audit.
• Ricostruzione: serve ricalcolare lo stato a partire dai fatti conservati, per esempio per correggere una regola di business o analizzare una situazione passata.
• Tracciabilità: è importante spiegare che cosa è successo e in quale ordine. Si può ricorrere a eventi di business oppure a una cronologia progettata per questo scopo.
• Consultazione dello stato corrente: la maggior parte delle schermate deve soltanto leggere lo stato attuale. Un modello tradizionale può offrire un percorso più diretto.

È utile anche verificare se il requisito è permanente e centrale per il prodotto o se riguarda un singolo processo. L’event sourcing è più adatto quando la sequenza delle modifiche è una parte essenziale del dominio, non soltanto quando qualcuno vuole «salvare tutto».

Criteri pratici per decidere

Valuta ciascun criterio con esempi reali del dominio. Non è necessario che tutti indichino l’event sourcing, ma occorre capire quale requisito sta guidando la scelta.

• Le modifiche hanno un significato proprio: «prenotazione confermata» o «rimborso approvato» sono fatti rilevanti, non semplici aggiornamenti di campi. Questo favorisce la modellazione di eventi espliciti.
• La ricostruzione è necessaria: l’azienda deve poter ottenere di nuovo stati precedenti o ricalcolarli applicando regole aggiornate. Se serve solo mostrare le modifiche più recenti, può bastare una cronologia.
• L’ordine è importante: la sequenza delle azioni determina il risultato e il team deve conservarla in modo affidabile.
• Esistono più viste dello stesso processo: team o funzioni diverse devono consultare gli stessi fatti in modi differenti. Le proiezioni possono soddisfare queste esigenze di lettura, ma comportano lavoro aggiuntivo.
• Il dominio prevede correzioni ed eccezioni: bisogna rappresentarle come nuovi fatti, per esempio una correzione o uno storno, senza cancellare in modo silenzioso ciò che è successo. Il significato di ogni evento va definito con attenzione.

Se l’esigenza si limita ad aggiornare record e consultare la versione corrente, il modello tradizionale sarà probabilmente più semplice. Se invece la cronologia deve essere completa, comprensibile e utilizzabile per ricavare gli stati, vale la pena approfondire l’event sourcing.

Costi, rischi e segnali per escluderlo

Conservare gli eventi non elimina la complessità: la sposta. Le letture spesso dipendono da proiezioni, cioè viste derivate che vengono aggiornate a partire dagli eventi. Se l’elaborazione è asincrona, può verificarsi una consistenza eventuale: per un certo intervallo, una lettura può restituire uno stato precedente. Il prodotto deve poterlo tollerare oppure definire come mostrare e gestire questo ritardo.

Inoltre, gli eventi persistiti non si modificano come normali righe di una tabella. Quando cambia il dominio, bisogna decidere come interpretare gli eventi più vecchi, come far evolvere i loro formati e come ricostruire le proiezioni. Servono anche procedure per rilevare gli errori di elaborazione, ripetere gli eventi quando è sicuro e gestire operazioni e supporto. Una sequenza incompleta o definita male può compromettere proprio la ricostruzione che si voleva ottenere.

È opportuno escludere o rimandare l’event sourcing se il team non sa spiegare quali eventi rappresentino fatti di business, se le consultazioni richieste sono semplici o se il sistema non deve ricostruire lo stato. È un campanello d’allarme anche il fatto che l’unica motivazione sia «avere un audit», senza requisiti relativi alle consultazioni storiche, alla conservazione o all’uso di quelle registrazioni. In questi casi, una tabella della cronologia ben progettata può raggiungere l’obiettivo con meno componenti.

Esempio ipotetico: ordini con modifiche e correzioni

Immaginiamo un’applicazione che gestisce ordini. Il team deve mostrare lo stato, l’importo e l’indirizzo attuali. Un modello tradizionale con i dati dell’ordine e una cronologia delle modifiche può essere sufficiente se l’obiettivo è consultare la versione corrente e spiegare gli aggiornamenti recenti.

La decisione cambia se l’azienda deve ricostruire come si è arrivati a un determinato importo, distinguere le conferme dalle correzioni e ricalcolare situazioni passate applicando nuove regole. L’event sourcing potrebbe registrare fatti come ordine creato, pagamento confermato e importo corretto. La vista dell’ordine deriverebbe da quella sequenza. Sarebbe però necessario decidere come rappresentare una correzione, come gestire gli eventi più vecchi e quali consultazioni potrebbero mostrare dati temporaneamente non aggiornati.

L’esempio non implica che ogni processo relativo agli ordini abbia bisogno dell’event sourcing. La scelta dipende da requisiti verificabili: quale ricostruzione è necessaria, chi consulta la cronologia e quale livello di complessità il team è in grado di gestire.

Domande da porsi prima di adottare l’event sourcing

1. Quale domanda concreta non trova risposta nello stato corrente e in una cronologia semplice?
2. Quali entità o processi devono poter essere ricostruiti, e per quale obiettivo di business?
3. Gli eventi descrivono fatti dal significato stabile o si limitano a copiare modifiche tecniche dei campi?
4. Quali viste occorre mantenere, chi le usa e quale ritardo è disposto ad accettare?
5. Come verranno gestiti correzioni, eventi duplicati, modifiche dei formati e rielaborazioni?
6. Chi sarà responsabile del monitoraggio delle proiezioni e della risoluzione degli errori di elaborazione?
7. Esiste un’alternativa più semplice che soddisfa i requisiti attuali senza precludere opzioni future?

Inizia con un ambito limitato e rivedi la decisione

Se i requisiti giustificano l’event sourcing, circoscrivi l’adozione a un processo la cui cronologia abbia un valore chiaro. Definisci prima il vocabolario degli eventi insieme ai responsabili del dominio e concorda che cosa garantisce ciascun evento: che cosa è accaduto, quali dati servono per interpretarlo e che cosa non deve cambiare in seguito. Prima di estendere l’ambito, progetta anche le consultazioni principali e le modalità di recupero delle proiezioni.

Registra le decisioni e rivedi l’architettura quando cambiano le esigenze. Se il prodotto non richiede più la ricostruzione, oppure il costo di mantenere le proiezioni supera la loro utilità, semplificare può essere ragionevole. Se emergono nuovi requisiti di tracciabilità e analisi, una cronologia convenzionale potrebbe non bastare più. La scelta migliore è quella che risponde a esigenze reali e che il team può gestire in modo affidabile, non quella che accumula in anticipo più meccanismi.