Costruire API più solide con i modelli di dominio Event-Sourced

Chiunque abbia lavorato su un progetto ereditato sa quanto sia frustrante. La documentazione è spesso assente o non corrisponde più alla realtà. La logica di business è sparpagliata in file diversi, le regole del dominio sono nascoste nelle migrazioni del database, e nessuno è più sicuro di come funzioni davvero il sistema.

Esiste un approccio diverso, e parte dall'event sourcing.

Perché l’event sourcing conta nello sviluppo moderno

L’event sourcing ribalta il modello tradizionale dei database. Invece di salvare solo lo stato corrente dei dati, si registra la storia completa delle modifiche che hanno portato a quel risultato. Ogni azione, ogni comando, ogni variazione diventa un evento immutabile, conservato in un registro.

Per chi sviluppa applicazioni cloud, API o microservizi, questo cambia parecchie cose:

• Auditabilità: il sistema produce automaticamente una traccia completa di tutto ciò che è accaduto
• Debugging: puoi ricostruire esattamente come si è arrivati a un determinato stato
• Scalabilità: separi le operazioni di scrittura (command) dalle letture (query)
• Chiarezza del dominio: ti costringe a riflettere su cosa succede davvero nel tuo business

Il problema è che l’event sourcing può sembrare complicato quando non ci si è ancora abituati.

Il ruolo del domain modeling che viene spesso trascurato

Qui entra il domain modeling. Prima di scrivere una sola riga di codice, bisogna definire chiaramente:

• Quali comandi provocano cambiamenti?
• Quali eventi vengono generati?
• Come comunicano tra loro le diverse parti del sistema?
• Quali regole devono rimanere sempre valide?

Questo lavoro di analisi è quello che distingue un sistema che cresce senza problemi da uno che diventa difficile da gestire. Ed è importante documentarlo e condividere il risultato con il team, anziché tenerlo solo nella testa o su una lavagna.

Un linguaggio per descrivere l’architettura event-sourced

È qui che entrano le linguaggi strutturati per il domain modeling. Non è necessario scrivere la logica del dominio in forma di prose o distribuirla tra decine di file di codice. Puoi invece esprimere l’architettura in un formato chiaro e leggibile da macchine, che include:

• Aggregates: le entità centrali che applicano le regole
• Events: i fatti che rappresentano ciò che è accaduto
• Commands: le richieste che uti