DEV Community

Cover image for Event Sourcing: la storia completa del tuo sistema
Dev-Iadicola
Dev-Iadicola

Posted on • Originally published at iadicola.it

Event Sourcing: la storia completa del tuo sistema

Il problema: lo stato corrente cancella la storia

Un conto corrente bancario ha un saldo di 1.500 EUR. Questo e lo stato corrente. Ma come ci e arrivato? Stipendio di 2.000, affitto di 800, spesa di 200, rimborso di 500. In un sistema tradizionale, il database contiene solo il saldo — la storia e persa. Se un'operazione e stata applicata per errore, non puoi ricostruire la sequenza. Se vuoi sapere qual era il saldo il 15 del mese scorso, devi averlo salvato esplicitamente.

L'Event Sourcing inverte il modello: invece di salvare lo stato corrente e aggiornarlo, salvi ogni evento che ha modificato lo stato. Lo stato corrente si ricostruisce riproducendo (replaying) gli eventi in sequenza. Il saldo e il risultato di: Deposited(2000) → Withdrawn(800) → Withdrawn(200) → Deposited(500) = 1500.

Come funziona: Event Store e Proiezioni

Event Store

Gli eventi vengono salvati in un event store — una tabella append-only dove ogni riga e un evento immutabile con: ID, aggregate ID, tipo evento, payload (dati dell'evento), timestamp, versione. Gli eventi non vengono mai modificati o cancellati. Sono fatti storici: "e successo questo, in questo momento, con questi dati".

Proiezioni (Read Models)

Lo stato corrente viene costruito da proiezioni: funzioni che ascoltano gli eventi e aggiornano viste materializzate ottimizzate per la lettura. Una proiezione "saldo corrente" somma depositi e sottrae prelievi. Una proiezione "movimenti mensili" raggruppa gli eventi per mese. Una proiezione "clienti con saldo negativo" filtra e aggrega.

Il potere delle proiezioni e che puoi crearle retroattivamente. Se domani serve un report che non esisteva ieri, crei una nuova proiezione che riproduce tutti gli eventi storici e costruisce il report dall'inizio dei tempi. Con un database tradizionale, i dati storici sono persi.

Esempio teorico: gestione ordini

Un ordine e-commerce attraversa molti stati. Con Event Sourcing, ogni transizione e un evento:

  • OrderCreated { items: [...], customer_id: 42 }
  • PaymentReceived { amount: 150.00, method: "card" }
  • OrderShipped { tracking: "IT123456", carrier: "GLS" }
  • OrderDelivered { signed_by: "Mario Rossi" }

Lo stato corrente dell'ordine si ricostruisce riproducendo gli eventi. Ma hai anche: audit trail completo (chi ha fatto cosa e quando), la possibilita di ricostruire lo stato a qualsiasi punto nel tempo, e proiezioni dedicate per dashboard, analytics e reporting.

Event Sourcing + CQRS: la combinazione naturale

Event Sourcing si combina naturalmente con CQRS: i Command scrivono eventi nell'event store. Le Query leggono dalle proiezioni. I due percorsi sono completamente separati e ottimizzati indipendentemente. Le proiezioni possono usare strutture dati diverse (tabelle SQL, documenti MongoDB, indici Elasticsearch) a seconda delle esigenze di lettura.

I costi reali

  • Complessità: il modello mentale e radicalmente diverso dal CRUD. Il team deve pensare in termini di eventi, non di stato.
  • Eventual consistency: le proiezioni non sono aggiornate istantaneamente. Tra la scrittura dell'evento e l'aggiornamento della proiezione c'e un ritardo (spesso millisecondi, ma non zero).
  • Schema evolution: gli eventi sono immutabili. Se il formato di un evento cambia, servono strategie di versioning (upcasting).
  • Storage: gli eventi si accumulano nel tempo. Un sistema con milioni di transazioni al giorno genera terabyte di eventi. Servono strategie di archiviazione e snapshot.

Quando usare Event Sourcing

  • Usa Event Sourcing quando l'audit trail completo e un requisito di business (finanza, sanita, legale)
  • Usa Event Sourcing quando devi poter ricostruire lo stato a qualsiasi punto nel tempo
  • Usa Event Sourcing quando le proiezioni retroattive hanno valore di business
  • Non usare Event Sourcing per CRUD semplici: il costo di complessità non si giustifica
  • Non usare Event Sourcing se il team non ha esperienza con sistemi event-driven: la curva di apprendimento e ripida

Event Sourcing non e un'architettura per tutti i progetti: e una strategia di persistenza per domini dove la storia ha valore. Quando lo stato corrente non basta e serve sapere come ci sei arrivato, Event Sourcing trasforma il database da una fotografia a un film completo.


👉 Leggi l'articolo completo su iadicola.it

Top comments (0)