Gitbaritalian
developer
podcast
7

Event Sourcing e CQRS. Scrivere software basandosi sui "FATTI"

Serie 1
Episodio 7
Durata 23 minuti

Contattami a: @brainrepo su twitter o via mail a info@gitbar.it

Gestire la complessità di un dominio complesso, farlo usando il domain driven design ed ereditare i vantaggi di avere una storia con l'event sourcing. In questa puntata parliamo di come gestire le complessita nel nostro software con DDD, ES e CQRS.

Alcuni link utili

Le sigle sono state prodotte da MondoComputazionale Registrato negli studi di Radio Nuoro Centrale Le musiche da Blan Kytt - RSPN

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

Benvenuti su Bar, il podcast dedicato al mondo dei developer.
In mezzo artigiani in mezzo artisti che ogni giorno infilavano le mani nel fango per creare nel modo più efficace possibile quei prodotti digitali che quotidianamente utilizziamo.
Settima puntata di Io sono il repo e stiamo trasmettendo dagli studi di Radio Numero Centrale per un'altra puntata un'altra puntata che ci introduce nel mondo delle sourcing.
Un saluto infatti a Giovanni che la' dietro la regia, sta pigiando tutti i bottoni per permettere alla mia voce di arrivare nel miglior modo possibile.
Infatti solitamente non sentite una voce con questa approfondita tranquilli, non è la mia voce, sono le magie dei microfoni della radio.
Comunque torniamo a noi e torniamo ai contenuti che è il motivo per cui questo podcast che esiste oggi parliamo di even sourcing.
Per parlare di sourcing dobbiamo in qualche modo immaginare una situazione.
Abbiamo appena sviluppato il nostro commercio, abbiamo il nostro carrello, i nostri prodotti, possiamo inserirli e a quel punto finalizzare l' ordine.
Bene, il nostro sistema va in produzione.
Dopo qualche settimana veniamo contattati dalla Business Business Unit che ci chiede la possibilità di avere accesso a tutte le volte che il nostro potenziale cliente inserisce elimina dei prodotti da carrello.
La prima cosa che ci viene in mente è quella di creare una nuova tabella e memorizzare questo tipo di transizione.
Ma la domanda ci deve e sorgere spontanea lo stiamo facendo nel modo corretto.
È uno degli elementi che ci in qualche modo suggeriscono che ci dicono che non lo stiamo facendo nel modo corretto.
È che in realtà stiamo duplicando la sorgente della verità.
Infatti l'insieme degli inserimenti e delle rimozioni da carrello è lo stato del carrello.
Quindi l'elemento dei prodotti sono due verità che noi dobbiamo in qualche modo interpretare all'interno del nostro sistema.
Ma la domanda, ripeto, e lo stiamo facendo nel modo corretto tutto il paradigma che stiamo utilizzando.
Infatti, il paradigma chiamato CRUD crudista perché i red caps dei crea leggi, modifica ed elimina questo tipo di paradigma va ad agire sullo Stato utilizzando dei pattern chiamati o Active Records data per, però la mia domanda è posso farlo in un modo diverso? Il modo diverso per poterlo fare si chiama Events Sourcing e come funziona? La base delle sourcing sono gli eventi, Gli eventi, se non sono altro che rappresentazioni di fatti, vengono descritti al passato e raccontano tutte le modifiche degli elementi di dominio elementi di dominio che sono in qualche modo creati e distrutti proprio da questi eventi.
Eventi legati alla logica di business.
Questi eventi vengono raggruppati in sequenze vanno a creare le blog, che non è altro.
Come vi dicevo, di una serie di eventi.
La lettura e l'analisi di questa serie di eventi vanno a creare uno stato.
Cosa ci permette di fare queste? La prima cosa che ci permette quella di non perdere estratti e livelli di informazione.
Infatti, leggendo gli eventi, tutti gli stati nei tempi che vanno dal primo evento all'ultimo, vengono memorizzati.
Gli Stati, infatti, non sono altro che interpretazioni di sequenze di eventi fino a un certo punto, per cui le letture e le Scritture, specialmente le scritture all'interno logo, non possono e non devono essere distruttive, per cui sono accomodamenti di eventi.
Per esempio, possiamo immaginare questa situazione.
Siamo all'interno di una nave e noi possiamo agire in due modi o dire io sono qui, quindi salvare la posizione e in questo caso io sto salvando uno Stato, oppure nel mio percorso posso salvare una serie di eventi che possono essere, per esempio, nella data tale dell'ora tale io mi trovavo in questa posizione e a seguire nella data tale dell'ora tale mi trovavo in questa altra posizione.
In questo caso io avrò una serie di eventi.
Questa serie di eventi mi permette di ricostruire l'intera storia per cui mi permette di conoscere lo Stato in qualunque istante per la barra dei tempi.
Un altro concetto importante e quello dell'aggregato che cos'e' l'aggregato è rappresentato da una serie di concetti che tendono a raggrupparsi naturalmente per formare delle unità concettuale.
Prima parlavamo di come è l'esempio più semplice e la coppia ordine e voce ordine entrambi, ma creare a completare il concetto ordine per cui la non è altro che un insieme di classi del nostro dominio che si raggruppano naturalmente e vanno a formare un insieme coeso e consistente dal punto di vista funzionale e l'esempio appunto dell' ordine della voce ordine eloquente naturalmente e tutte le modifiche che vanno ad agire all'interno delle classi del nostro aggregato e siano entità di modello oppure getto corrispondono a una transazione è la cancellazione di un elemento all'interno implica la cancellazione di tutti gli altri elementi dello stesso aggregato.
Cioè se io vado a cancellare l'aggregato.
A quel punto cancello tutti gli oggetti che lo compongono.
Naturalmente la un'altra particolarità che può essere trasportato.
Questo è particolarmente utile nel momento in cui ragioniamo in termini di architetture distribuite quindi di micro servizi.
Cioè può essere in qualche modo compatta, abile trasferito da una parte all'altra l'aggregato però ha una porta che si chiama aggregata.
Questa porta permette di certi comandi, ne gestisce la consistenza.
Un aggregato maneggia i comandi e applica agli eventi.
Ma a questo punto è importante sapere cosa sono i comandi e cosa sono gli eventi.
I comandi sono le azioni.
Quindi sono tutte quegli elementi quelle quelle quelle quelle azioni che noi possiamo in qualche modo fare verso quel l'elemento del dominio.
Per esempio l' ordine.
Noi possiamo creare un ordine.
Possiamo eliminare un ordine.
Possiamo aggiornare un ordine e fino a qua puo' puoi tornarci un po' l'immagine del cloud.
Ma se vi dico che possiamo inoltrare un ordine, spedire un ordine oppure possiamo preparare un ordine per la spedizione, possiamo annullare un ordine.
Tutte queste informazioni tutti questi comandi vengono passati attraverso Ruth che li trasforma in eventi.
Eventi che poi vengono in qualche modo salvati all'interno del nostro che in un secondo momento possono essere presi applicati al nostro aggregato per permettere la verifica delle invarianti.
Cosa sono le invarianti? Le invarianti sono le le regole di business di un certo aggregato faccio l'esempio io non posso inserire un prodotto nell' ordine se questo ordine è stato annullato e questo è un invariante per verificare se l'ordine è stato annullato, io devo leggere tutti gli eventi relativi a applicarle un certo aggregato e a quel punto posso sapere se in quella ha consistenza e quindi viene appunto verificata la consistenza.
La trama di tutto il discorso che ho fatto fino a questo punto è strettamente legato al domande rivende.
Infatti quando parlo di aggregato parlo di entità e parlo di questi elementi.
Sto parlando di una rappresentazione del mondo reale in codice, quindi dove il mio codice è strettamente legato alla logica di business.
In realtà però le vene può anche essere applicato in domini, in situazioni dove diciamo la verifica e la generazione degli eventi non è strettamente legata alla logica di business e quindi in contesti non legati a un dominio.
Stringendo in quel caso la trasformazione raccomando ed evento viene fatta.
È in qualche modo da una transazione di tipo procedurale.
A questo punto il ragionamento da fare è bene io ho una serie di eventi.
Questi eventi mi compongono uno stato nel momento in cui devo applicare un comando, lo applica un aggregato che in qualche modo verifica le invarianti, caricandosi se ne ha bisogno, naturalmente gli eventi e verificando se quella azione che io sto andando a fare su e consistente.
Ma fino ad ora abbiamo parlato di azioni all'interno del dominio, ma sappiamo che il nostro sistema ha bisogno anche di letture, cioè di accesso all'informazione.
Per avere l'accesso all'informazione dobbiamo scomodare un altro concetto si' chiamaci us command in quelli responsibility segue cosa vuol dire che è i comandi e le query.
Quindi le azioni e le letture hanno due responsabilità differenti, trattano l'aggregato in modo completamente differente.
Per esempio le quelli potrebbero non essere strettamente legate alla logica di business, perché io voglio un report della lista degli ordini, delle date, degli ordini a me, dei delle modalità di spedizione di quell' ordine.
Potrebbe in quel caso non interessarmi più di tanto.
Per cui perché devo andare a portarmi dietro una logica di business articolata quando in fase di lettura.
Io ho bisogno solo di un'informazione.
Se lo stato di Quell'elemento è figlio di una serie di eventi la cui lettura, analisi e generazione è complessa perché è figlia di una applicazione di una serie di eventi, certo aggregato, tutto questo si complica e qui, appunto, viene in aiuto, il che resse, che non fa altro che semplificare la fase di ricalcolo dello Stato, che è un processo particolarmente lento, specialmente quando ci sono un sacco di eventi.
A quel punto entra in gioco un concetto che si chiama proiettore cos'è il proiettore.
Il proyecto non è altro che un, quindi un mangiatore di eventi e non fa altro che andare a leggere gli eventi, creare degli stati, ma che sono strettamente legati alla logica di visualizzazione di lettura che noi abbiamo facendo.
Così noi riusciamo ad avere da una parte una serie di comandi strettamente legati alla logica di comando, quindi strettamente legati all'azione che sto andando a fare.
Dall'altra parte abbiamo invece una serie di dati di stati pensati e strutturati con il concetto della lettura.
Questo ci è particolarmente utile nel momento in cui le nostre applicazioni diventano complesse.
Certo, è un po' sovradimensionato se la nostra applicazione è una semplice applicazione di magazzino che ci deve dire quanti, quante uova ci sono in quella linea di scaffale, però nel momento in cui agisco e sviluppo, per esempio una del conto corrente bene avere la mia schermata che mi dice il saldo e può essere figlia di un'analisi, di una lettura di un'applicazione degli eventi con la con la finalità appunto di andare a generare quella schermata.
Per cui anche il lato intreccio il concetto che sto applicando è completamente diverso.
Naturalmente cosa fanno le proprie action? Generano delle snapshot, quindi generano, calcolano e disegnano delle fotografie dello stato.
A un certo momento queste snapshot hanno diciamo la generazione di queste snapshot ha un certo come posso dire un certo peso, un certo costo in termini computazionali e quindi a questo punto entrano in gioco tutta un'altra serie di strumenti che ci semplificano la generazione.
Un esempio e per esempio un sistema di cash che ci permette di salvare uno stato.
A un certo punto memorizzarlo ok memorizzare questa proiezione e a quel punto quando devo rigenerare lo stato in un momento successivo non faccio altro che applicare tutti gli eventi successivi allo stato che ho già generato in questo caso io ottimizzando la generazione appunto della proiezione, naturalmente.
E possiamo farlo in background, anche perché il fatto che non ci sono modifiche non ci sono alterazioni dei dati rende il nostro sistema tollerante alla sincronicità.
Per cui io questo questo questo questa generazione di di di, di di di snap shot, di proiezione posso farla anche in background e magari dire al nostro utente se non l'ho ancora giornata dammi qualche istante e' un po' quello che succede qui i nostri sistemi bancari no.
Quando vediamo il saldo disponibile sì, ma poi vediamo il saldo contabile e non è sempre aggiornato all'ultimo istante.
Questo perché appunto, lo Stato deve essere generato, deve essere generato dalla lettura degli eventi.
Quali sono i vantaggi di un sistema che si basa sulle pensioni Singh? Beh, è possibile in qualunque momento fare un audit, quindi andare a vedere successo in un dato momento è possibile anche fare attività di lividi di riavvolgimento.
Chiamiamole anche attività che la tela l'analisi che si chiama Motif cosa? Se quindi se fosse successo questo cosa sarebbe? Cosa ci saremmo trovati? E', per esempio, più facile capire quale evento ha scatenato una certa situazione rende il nostro sistema tollerante al fatto che possa mancare e di apparire.
La connessione, quindi ha dei sistemi che sono occasionalmente connessi.
Questo perché non ci può.
Non possiamo perdere la coerenza accordando semplicemente dei dati.
Non andiamo a modificare gli Stati per cui qui il nostro sistema è tollerante alla sincronicità e quindi anche tollerante.
Alle connessioni asincrono è possibile correggere la storia, quindi una serie di eventi.
Ho sbagliato qualcosa perche' il mio sistema.
Ho introdotto un baco nel mio sistema e mi ha generato un errore in un certo evento.
Esiste un modo semplicissimo per correggere la storia senza pasticciare lo Stato.
Così come facciamo quando abbiamo un'applicazione che utilizza il crudo.
Per esempio, posso farlo semplicemente inserendo un altro evento.
Questo nuovo evento va in qualche modo a correggere la storia e a riportarmi a uno stato in qualche modo veritiero.
Non perdo dati, quindi non perdo situazioni in certi punti del tempo e posso, cosa molto importante, reinterpretare il passato.
Ritorniamo al ragionamento che ho fatto prima.
Prima ho detto io ho sviluppato il mio.
È poi arrivato il marketing e mi ha chiesto se i Breen repo voglio sapere chi inserisce è elimina elementi nel carrello.
Se avessi ragionato in ottica di Eve applicandole nel sistema e avrei potuto rispondere senza nessun tipo di problema alla business ione, così come se domani la business mi chiede di leggere delle situazioni particolari e io salvo tutti gli eventi, io ho una visione o quasi la registrazione video di quello che è successo e quindi posso a posteriori cercare delle informazioni che invece non potrei trovare.
Nel momento in cui vado io vado a salvare lo stato.
Naturalmente non tutto viene solo con vantaggi.
Ci sono anche degli svantaggi quali sono? Senza dubbio il primo è che o per chi le applicazioni semplici, cioè il fatto di utilizzare le generare le proiezioni nel caso, le vogliamo generare, volessimo generare eh? Fare tutte queste azioni beh, moltiplica le righe di codice e quindi questo se vogliamo fare una semplice applicazione, come vi dicevo prima, è in qualche modo sovradimensionato.
La seconda è che potrebbe non essere sincrono o comunque per renderlo sincrono.
Abbiamo dei costi.
Perché? Perché gli eventi possono essere tanti e la generazione di uno stato potrebbe richiedere risorse.
Queste risorse potrei non averle tutte a disposizione, quindi questo mi porta in una condizione tale per cui il mio sistema non è sincrono.
Quindi in qualche modo in qualche modo esistono della della dei limiti.
Per esempio, il Croods si dimostra molto piu' efficiente quando vado a salvare dei dati e quindi quando i dati non hanno delle semantiche o dei processi particolari di business.
E quindi il salvataggio lato lato cloud è molto più semplificato, così come più semplificata la ricerca.
Perché? Perché se io vado a cercare cerco su uno stato.
Solitamente quando faccio una ricerca all'interno della mia applicazione, cerco su uno stato dico solitamente perché in realtà mi potreste dire sì, va bene, ma io voglio cercare anche sugli eventi.
Va bene, ma se non vuoi cercare sugli eventi, solitamente tu vai a cercare sullo Stato.
Quando venne a cercare su uno stato, tu cerchi su una conseguenza, cerchi su una conseguenza.
Questa conseguenza deve essere generata.
Quindi in qualche modo tu devi generare tutta una serie di stati figli di un evento che vuol dire utilizzare delle risorse e questo ha dei costi.
Ecco il crudo No, non ha dei costi perché tu hai già lo Stato.
Stai salvando già lo Stato.
Quindi questo questo questo doppio passaggio lo saldi e poi naturalmente in questo caso col crudo tu hai una serie di indici che ti possono essere utili appunto per velocizzare il processo di ricerca.
Bene, mi rendo conto che ho buttato tanta carne al fuoco.
Io spero di avervi in qualche modo interessato e introdotto anche un modo, un po' caotico nel mondo delle sourcing e del e non volevo essere esaustivo, ma in qualche modo mi piaceva proprio mettervi la la la la pulce nell'orecchio Noi ci sentiamo la prossima settimana.
Ringraziamo Giovanni tutela di una centrale che si sono dimostrati molto disponibili a darci appunto in uso gli studi della radio e nulla l'unica, cosa che vi chiedo è quella di Se vi fa piacere iscrivetevi al podcast con la vostra applicazione.
Queste dalla settima puntata da bere il repo e' tutto un saluto la prossima settimana bar il circolo dei full stack e' bello.
Per una volta a settimana ci troviamo davanti a due birre e comprendere Pippo.
Parliamo linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fusti
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄