Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al GITBAR e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su GITBAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Secondo episodio in due giorni e tra qualche ora registreremo anche il terzo, quindi tipo un tour de force di GITBAR.Vediamo se riusciamo ad arrivare alla prossima puntata senza soccombere sotto il peso delle nostre parole e dei nostri microfoni.Detto questo io saluto i miei compagni di viaggio da una parte abbiamo il buon vecchio Carmine.Ciao Carmine! Buonasera, lo vedete qui in versione docker, proprio così con il cappello da scaricatore di porto.E dall'altra parte abbiamo Alessio col suo nano da camera.Se vede perché io ho la cosa della registrazione Grande, grande, il mio preferito ragazzi Nano da camera in mano sfornata Per chi l'avesse perso basta guardare la puntata della settimana scorsa dove abbiamo perso un buon tre quattro minuti a parlare del Fantastico, non è la camera di alessio ne vorrei uno devo trovare il modo per procurarmi Detto questo rapidamente ricordiamo i nostri contatti info chiuso la guitar punto itat brain repo su twitter Il gruppo telegram potete cercare appietto per il vostro client di telegram preferito e ci trovate lì siamo più di 1000 persone 1300 ma soprattutto it 9 6 8 4 che li imbanna te, te prendremo, da cui potete mandare bonifici.È stato velocissimo Ale, si è ricalibrato subito, perché io sono sicuro che nel suo cervello gli è venuto subito in mente "Buy me a coffee" e hai ricalibrato subito.Se ci volete supportare, come dice il buon Alessio, potete darci una mano a sostenere le spese di Gitbar proprio attraverso una donazione, abbiamo l'area supportaci nel sito dove ci sono insomma tutte le modalità oppure potete farlo con i metodi del podcasting 2.0 quindi con un'app di podcasting 2.0, un'app avanzata, potete mandarci dei boost o fare streaming di Satoshi per supportare l'episodio di Gitbar.Devo anche ricordarvi a proposito di supporto che Gitbar è supportato da Fisco Zen che con appunto la sua partnership ci ha dato una mano e ci dà una mano proprio per produrre questa puntata ma di Fisco Zen ne parleremo tra un pochino Prima di iniziare l'ultima cosa l'ultimo preambolo poi andiamo direttamente alla ciccia promesso quindi zero zero preamboli zero chiacchiere introduttive.Canale YouTube abbiamo un nuovo canale YouTube se non l'avete ancora fatto mi raccomando iscrivetevi e cliccate sul campanaccio che è il modo per intanto rimanere aggiornati appunto sui nuovi episodi e poi insomma entrare a far parte di quella parte della comunità.Quindi mi mi raccomando fatele poi vedete i nostri bei faccioni perché privarsene detto questo sai che cosa dobbiamo fare un servizio che a cui tu fai subscribe tipo così e quello prende quando noi pubblichiamo un video ti manda una raccomandata con le API deposte italiane una bella raccomandata a casa si demanda.Trascrizione trascritta a mano.Ma guarda che non è male.Se consideriamo che effettivamente la raccomandata online poi viene stampata, cioè quindi effettivamente c'è già un processo per fare questa cosa.Si si, certo.Noi in esperienza professionale usavamo sta roba con l'API.Stampata così mi ricorda molto Elon Musk che chiede agli ingegneri di Tesla di fare code review di Twitter.Non so se l'avevate letto, no? Il fatto che ha chiesto agli ingegneri di Twitter di stampare il codice.Ma tu all'università come facevi? Uguale a Samu Aride.- Almeno era pseudocodice là, no? - No, no, noi facevamo proprio C, cioè noi facevamo C e C++ sulla carta e se ti scordavi il punte virgola, il professore aveva la penna rossa, una cosa ridicola, cioè, per carità.- Ma ma cazzo lo compilavi? - A mente, così, aveva le LVM nel cervello che faceva...mannaggia.Vabbè, bei tempi mi hai aperto il mondo dove si facciano gli interrupt sul foglio di carta facendo assembly, mamma mia.Esatto, che bello.Io sono quello che forse ha fatto l'ultimo esame nuovo, spam temporale, insomma, un po' più ridotto rispetto ai vostri.Ci stai dando dei boomer, capito? No, no, però nel senso so di essere ancora quello che più o meno resistente ancora e si fanno ancora insomma così perché è bello perché il professore si deve aggiornare quando può.Ehhh ci sta, ho capito.Quando non può, cioè nel senso oggi ho il cappello da persona polemica quindi andrà un po' così.E allora tiriamo fuori un argomento che scalda le polemiche.Oggi proviamo a parlare di una cosa, in realtà ne parliamo un bel po' di anni fa, ne parliamo un bel po', grazie amore mio, sei bravissima! Ah, yes, I am recording, and this part of the episode I will not cut it, eh, I will keep it as it is.Grande, salutiamo la moglie di Mauro, che è tipo la moglie del tenente Colombo, voi non l'avete mai vista, ma esiste.questo si chiama amore matrimoniale i genitori di mucca e pollo poi li vedi in manga la mamma e il papà di mucca e pollo vedi solo i piedi comunque detto questo parliamo di CQRS in realtà parliamo di event sourcing che in qualche modo tocca un po' l'argomento di oggi perché parleremo di CQRS-ES, perché le sigle non sono mai abbastanza.Insomma, il CQRS è un argomento che spacca molto, no? Ci sono i pragmatic...non mi viene da chiamarli pragmatic programmer, ma le persone un pochino più pragmatiche che dicono "Eh, vabbè, ma CQRS, ma sei sicuro? sei davvero sicuro che quello che vuoi fare non sia un crude perché la c'è la famosa riduzio a crude no? e dall'altra parte c'è l'omino di cqrs che dice no non è un crude, magari anche mettendo che ogni programma è un crude quindi se non è un crude è un crude col crude degli altri come si sul dire, nel senso che da qualche parte i dati devono essere ingestati però sto già iniziando a fare polemica, io sono solo nella presentazione, nell'argomento, quindi super fiocco.Morale della favola, si parla di CQRS, Command Query Responsibility Segregation, ES, quindi Event Sourcing.Detto questo ragazzi, io lascio direttamente il microfono a voi per provare a rappresentare modo più facile possibile il concetto di CQRS-S.Vai Carmine! Proviamo così a caso, proviamo da un problema reale.Allora avete questo endpoint in post dove ricevete un sacco di...avete diversi end point in post, dove ricevete, non lo so, diversi tipi di dati, ok? C'è chi si iscrive alla vostra app, c'è chi fa l'ordine per il ristorante, c'è il ristorante che aggiorna il menu, eccetera eccetera e ad un certo punto avete come feature quella di creare diciamo delle entità, ok? quindi sostanzialmente di leggere delle cose che sono cross, tutti questi contesti, e che sono diverse, diciamo, dall'entità in sé, ok? Al che si ingegna, si fa select, si fa join, si fa questa bella struttura di mezzo dove ci metti le cose e la restituisci.e questa cosa va ripetuta, iterata, finché ad un certo punto non vi rendete conto, e questa cosa mi è successa, per magari vi spiego anche come, che quello che voi scrivete è effettivamente diverso da quello che voi leggete, però voi scrivete e leggete sempre le stesse cose nello stesso posto e ad un certo punto arriva il collega posto e gli dice "no, per risolvere questa cosa dobbiamo fare una data pipeline, mettiamo un data broker, mandiamo l'evento, facciamo un altro microservizio".E bene.E se invece avreste diviso la parte che scrive e dalla parte che legge fin dall'inizio, non sto parlando di event sourcing, event, l'app end on, eccetera eccetera.Se avessi semplicemente diviso la parte che scrive, che sostanzialmente invia un comando, io non lo so, iscrivi l'utente e non dite che non lo fate già, ho visto troppe post, ho visto troppe get che non vanno su nessuna risorsa, ma diciamo tipo il comando scritto come la vecchia roba soppa.Quindi immaginate che avete effettivamente una cosa del genere, creata per essere questa cosa qui, che scrive.E avete da tutt'altra parte, da tutt'altra parte, insomma, in un posto di versi del codice, qualcosa che vi fa leggere quello che dovete leggere, quindi che possa questa entità che è cross cose, una cosa totalmente diversa e avete un modo in cui ciò che voi avete scritto che ha quella forma lì e che non viene cambiata in qualche in qualche modo triggera la creazione di queste entità che vi servono solo per leggere.Questo è il ciclo adesso.Spiado malissimo.No in realtà in realtà è interessante quello che dici nel senso che ho provato a farmi questa domanda mentre parlavi perché secondo me può essere un grande di fattore di differenziazione, discriminatore.Cioè se quello che noi stiamo facendo non fitta con un API RESTful, forse siamo nel dominio del CQRS, cioè forse il CQRS ci può dare una mano.Dico forse, io ricordo un po' di anni fa l'ho utilizzato e l'ho utilizzato, giusto per portare un esempio pratico, l'ho utilizzato quando sviluppai la prima versione del mio booking, dove la lettura della disponibilità dei posti in escursione, in fuoristrada, era un processo completamente diverso dalla scrittura, perché la lettura veniva fatta in fase di prenotazione con tutta la sua logica di business, che era abbastanza complessa, perché c'era gli allotment, erano mille cazzi, prenotazioni con disponibilità incrociate, cose varie.Dall'altra parte, però...Ah che bello! Questa è nuova! E questa puntata è sponsorizzata da...Dalla fotocamera che si spegne! Dalla fotocamera che si spegne! La bagassa grande! Va beh, farete a meno del mio faccione per ora, perché in realtà non posso switchare camera nel frattempo.Ma che cazzo, vabbè.Va beh, poco male insomma.Dicevo, in realtà era molto utile questa cosa, o almeno per me lo è stato, perché mi ha messo in condizione di proprio dividere la parte di scrittura, cioè la parte nella quale io andavo a impostare a settare la disponibilità dalla parte in cui la leggevo per esempio quando settavo la disponibilità era o in fase di configurazione e la un po' puzzava di crudo no? Quando io sto creando il mio servizio ci sono 100 posti lunedì ma una parte di scrittura della disponibilità e su questo ci andiamo a ragionare era la parte della prenotazione, quando io sottraevo disponibilità, che in realtà non era una scrittura sulla disponibilità perché utilizzavo la tecnica dell'event sourcing che vediamo tra un po' E quindi ecco quello era un caso, perché? Perché quello che ho esperito proprio all'inizio, quando ho pensato questi end point, era che il RESTful non mi avrebbe risolto il problema ma in realtà secondo me è interessante di, è interessante dire anche che spesso si pensa che sono due cose esclusive, in realtà non lo sono.Sì, è la stessa cosa.E l'applicazione su cui lavoriamo, io adesso esattamente così, c'è una parte che è crude e c'è una parte invece dove c'è il CQRS, cioè nel senso alla fine non stiamo parlando di nulla, cioè, non so, voglio un po' demistificare la cosa, ma sto parlando di nulla di complesso e nulla che magari richiede chissà quale framework si ha dal punto di vista ecologico punto di stamentale.Cioè, c'avete la vostra e rest, poi c'avete un end point che accetta questi comandi, questi comandi vanno a scrivere in un altro TBI, in un'altra tabella, in un altro schema, c'è una roba che aggiorna, una volta che si scrive qualcosa, la parte diciamo in letto, quindi si fa una proiezione di ciò che scrivi con quello che legge, quindi andate a creare in un'altra tabella magari ciò che effettivamente l'entità che volete leggere.In lettura avete un endpoint che vi legge quella roba lì e in lettura potete anche fare questo trick di farlo RESTful perché magari state proprio creando un'entità nuova che in scrittura non c'è perché nulla scrivi.In lettura però c'è, almeno non è niente di straordinario insomma, senza Event Sourcing.Poi con l'Event Sourcing cosa ne parli? Devent Sourcing è un'altra cosa, di quello ne parliamo tra poco.Ah, vedi, è tornato Mauro, siamo live.Sono riapparso.Diciamo che secondo me la cosa importante, almeno per quella che è...Allora, io non sono un grande navigato del CQRS, non l'ho fatto per una vita.Lo faccio da due anni in produzione, ma quello è un altro conto.Lo faccio perché il linguaggio che utilizziamo noi per fare questa cosa, che è Elixir, offre effettivamente degli strumenti che io non ho trovato altrove, mettiamola così, per fare 5 RS.Elixir ha un framework della madonna per fare 5 RS che è Commanded.La cosa su cui...e Elixir fa una cosa...Cioè, Commanded fa una cosa particolare che non so se altri framework 5RS fanno, questo Carmine probabilmente lo sa di più, che è tenere gli aggregati in memoria.Ok, stiamo parlando...Probabilmente no.Scusatemi.Stiamo parlando di...Stiamo tirando dentro anche alcuni concetti che vengono però dal domain driven design che forse ha senso ripetere.Si ha senso introdurlo.Praticamente il domain driven design è tutta sta roba che poi alla fine è stata infusa a pressione nel CQRS e quando si parla del CQRS c'è di fatto il paradigma se li porta dietro per cui io mi vado a prendere tutti i concetti del domain driven design perché magari mi scordo qualcosa e ho paura.Hai iniziato con gli aggregati ma a noi ci interessa parlare di aggregati, entità e value object.No perché in realtà no c'è nel senso il context già è un'altra cosa cioè nel senso un bounded context è una cosa che conoscono tanti programmatori per chi non lo conosce un Boundary Context è quando tu hai il tuo contesto, cioè Amazon, hai il contesto del carrello dove metti le cose e avrai quell'API per il carrello per aggiungere gli elementi, toglie gli elementi, aumenta la quantità degli elementi eccetera eccetera e poi c'avrai il contesto dei pagamenti che è un'altra cosa dove tu avrai le tue API per fare i tuoi pagamenti con la tua carta di credito, le tue cose, aggiungi la carta di credito, togli la carta di credito, come il firmato di perdone, allunghi le gambe, sposta le gambe, io gli taglierei le gambe, per cui praticamente alla fine i building block del 5RS sono chiaramente il dominio, cioè il dominio è questa cosa, questa palla enorme in cui vive la nostra applicazione, che è piena di concetti, che mappano sui contesti, poi dopo di che abbiamo le cose che sono importanti per me, sono gli aggregati, che sono sostanzialmente delle entità che vivono in memoria e che sostanzialmente hanno uno stato interno e il loro stato interno cambia a seconda dei comandi che ricevono e degli eventi che disperciano.I comandi e gli eventi poi sono la cosa secondo me importante del 5RS e del Domain Driven Design, che secondo me aiutano anche là, cioè andiamo a fare sempre sul Domain Driven Design, aiutano a fare untangle di un dominio particolarmente complicato, che magari quando uno parte col prototipo a cazzo dei cane, col crude, tante domande non se le fa, e ci sono anche dei toolkit proprio di facilitazione per fare queste cose tipo l'event storming che è una cosa inventata da Alberto Brandolini che praticamente ti fa mettere su un muro pieno dei post-it tutti i post-it con i tuoi comandi, con i tuoi eventi, con i tuoi aggregati e tutta roba a cannone finché che te ne vengono in mente e poi fai il refinement di quelle cose là.E diciamo, i comandi sono molto importanti perché sono l'entità che viene dispatchata, che passa per un command dispatcher e che praticamente arrivano agli aggregati e gli aggregati poi decidono come reagire a questi comandi tipo se mi arriva il comando aggiungi questa cosa sul carrello io poi da aggregato carrello dispatcho l'evento cosa ha aggiunto al carrello e reagisco a questa cosa qua mi rendo conto che è molto complicato da spiegare cioè finchè uno non lo vede in azione questa cosa è veramente complicata da spiegare se vogliamo fare proprio diciamo una Se vogliamo fare esempio come l'esempio di commanded in realtà dove gli aggregati sono tenuti in memoria è più semplice ok Perché c'è un c'è un solo DB ok, nel senso, cioè in realtà due ce ne sono, uno è quello dove ci sono gli eventi, uno è quello dove ci sono i read model, le proiezioni, no? Quello che abbiamo detto prima, quello che leggi.Quindi come funziona, tu hai il endpoint che invia il comando, ogni comando viene ricevuto da un aggregato, quindi l'aggregato riceve il comando, modifica il suo stato interno, quindi è come se fosse la parte di scrittura, ok, che viene creata a partire dalla sequenza degli eventi che poi triggerà delle proiezioni che sono in ascolto sugli eventi.Quindi alla fine è questo, l'aggregato riceve il comando ed emette l'evento.Questo evento viene raccolto dall'aggregato stesso, ok, se deve modificare il suo stack interno, ma può essere accolto anche da un proiettore che prende questo e dice "ok è successo questa cosa qui o questo payload" e va a scrivere sul DB quello che vi volete leggere.Va a scrivere sul DB oppure a fare qualsiasi side-effect.Può fare qualsiasi altra cosa, infatti noi con alcuni ci si manda le mail, ci si mandano le notifiche nel browser.Alla fine è questo, la parte importante è l'aggregato.paradossalmente potreste avere solo gli aggregati senza nessun read mode per quanto possa essere assurdo potrei fare questa cosa ma questa è la specificità di commanded se avete un framework, come volete far voi, dove l'aggregato viene persistito quindi non è in memoria per questioni di performance, di che non so di qualunque cosa, le regole sono sempre le stesse.L'aggregato viene ricostruito leggendo gli eventi che gli appartengono.È una cosa veramente astra...Allora, proviamo a fare un po'...Aspetta, finiamo le definizioni, così poi a ruota libera.L'event sourcing è l'abilità/pratica di ricostruire lo stato di un aggregato facendo replay degli eventi che sono una lista.Semplicemente quando noi attacchiamo il nostro framework, la nostra applicazione 5RS a un event store, che è quello che fa lo storage degli eventi, quella quando fa il boot se prende da livestore tutti gli eventi vecchi, se li giuccia, fa replay e ricostruisce lo stato dell'aggregato a partire da quelli e quindi noi praticamente abbiamo questa cosa che è molto fault-tolerant, è un meccanismo molto simile a quello che usano penso le banche, che hanno il loro libro mastro di tutte le cose che sono successo e tu quando è molto figo perché tra l'altro puoi fare tipo macchina del tempo cioè in un punto x del tuo dominio dieci anni fa alla fine puoi andare a vedere che cosa è successo proprio facendo inspect dell'invent store è una cosa molto potente.Caso pratico proviamo proviamo a rappresentare un attimo quello che abbiamo detto perché ci sono concetti che vengono dal CQRS, con ct che vengono dal domain driven design.Allora immaginiamo la mia applicazione di prenotazione, quella di cui vi ho parlato all'inizio.L'aggregato possiamo rappresentarlo come...vi ricordate la programmazione oggetti dove ogni oggetto aveva uno stato interno e una serie di metodi per alterare lo stato? L'aggregato può essere una classe infatti, "improve" adesso Marco Pivetta mi sfonna, però "improve" è una classe immagino.Esatto, immaginate qualcosa di un pochino più esteso che può contenere altri elementi che vivono di vita propria, altre classi all'interno, che ne so.L'aggregato "reservation" può contenere l'entità "price", l'entità "availability" e tutta una serie di elementi.L'aggregato è quel pezzo di dominio Che fa tutta una serie di operazioni magiche dentro che vive che rappresenta che modella la realtà Adesso secondo quello che mi avete detto noi dobbiamo interagire con l'aggregato il modo classico Rest rest full o simil restfull perché di restfull veri ne ho visto veramente pochi in vita mia è quello di prendere un aggregato su e parti e ti può attaccarci come quando fanno che attacca nei necrologi no proprio staccarcelo sopra con violenza e peggiare pezzi di aggregato, aggregati così manualmente.Che ha senso, però ci sono dei casi dove in realtà ha senso che l'ecosistema che vive, il micromondo che vive dentro l'allegato reagisca a degli stimoli esterni.Questi stimoli esterni, secondo quello che ci hanno detto poco fa, Carmine e Alessio, sono gli eventi che alterano il mondo aggregato, ok? Che è un mondo, un concetto definito dal domain driven design.Questi eventi vanno, alterano e cambiano lo stato dell'aggregato.Naturalmente lo stato cambia, si altera.Alessio e Carmine hanno introdotto anche l'event sourcing che è come ci hanno detto prima è un modo per tenere traccia di queste alterazioni quindi io non mi ricordo il mondo diciamo oltre a custodire lo stato corrente custodisce praticamente tutta la sua storia tutte le sue versioni precedenti è il suo stato corrente e la somma l'applicazione di tutta la sua evoluzione di tutti i suoi diff se vogliamo parlare in termini è una grande reduce su un array praticamente sì oppure oppure è tipo quello che facciamo in git fondamentalmente sì è è la stessa cosa.Sì, è uguale.Ma alla fine, giusto così, per dare anche un po' di chiarezza così, CQRS ed Open Sourcing non sono la stessa cosa, possono anche non essere patti, possono anche non stare insieme.Il CQRS senza Open Sourcing, e come abbiamo detto prima, una parte scrive e una parte legge, semplicemente sulla parte che scrivi tu salvi lo stato corrente.se non vuoi fare all'aggregato non fai un mega aspetta però mi sto perdendo però io scrivo lo stato corrente però anche quando faccio rest full cosa sì ma la parte di scrittura e la parte di lettura sono comunque separato non è la stessa cosa perché quando tu fai rest C'hai per esempio il tuo controller che scrive su due tabelle.La cosa che non puoi fare in REST, se tu fai 5 RS senza IS, io non l'ho mai fatto 5 RS senza IS, io ho un sacco di bias, però la cosa che non puoi fare è...Cioè, il concetto che non abbiamo spiegato è quello dei read model.Praticamente tutta questa parte diventa super figa quando tu all'aggregato gli attacchi il proiettore.Dove il proiettore è quello che oltre a fare tanti side effects, chiaramente tu ci scrivi pure sul database quel proiettore.È uno dei usi più comuni del proiettore.Quindi tu prendi la tua bella tabella del database e quando arriva l'evento vipo bluto tu ci scrivi sopra però la cosa importante è quella tabella che tu hai sul database la chiami read model e tu non vai a leggere dallo stato dell'aggregato vai a leggere dal read model che sta sul database e tu dici ma allora sta roba a che serve? Se non lavoro in termini di event sourcing, dove alla fine io mi salvo tutti gli eventi e poi ho bisogno di un punto nel tempo dove ho un'immagine rappresentabile, uno snapshot di quello che sta succedendo nel mio dominio, a cosa mi serve? Ma non solo.Allora, il punto è questo, è che i read model, quando tu attacchi, può essere un read model e a quel punto stai a fare la stessa cosa che fai col crude, semplice, ma possono essere più read model, perché tu la tua API puoi avere una phase aid, se vogliamo, su un dato che è fatto in un modo, che è fatto in un altro modo, ma che derivano dallo stesso aggregato, tipo un pezzo del carrello di Amazon o un altro pezzo del carrello di Amazon.Che cosa significa? Che nel momento in cui io ho diverse necessità, a livello per esempio dei front-end, posso andarmi a costruire i miei read model, restituendoli anche secchi tramite un API, nel modo in cui servono al frontend, senza la necessità di andare a fare manipolazioni strane solo perché il frontend ha deciso che oggi gli serve un campo in più, un campo in meno, eccetera, eccetera.Questo che significa? Questo accoppiato con l'event sourcing significa che se io devo modificare il model, poi a un certo punto basta che sbraco il database e il read model viene ricostruito a partire l'event sourcing e questa è una cosa molto potente perché il read model 1 viene ricostituito a parte dal database dall'event sourcing ma soprattutto se io ho attaccato i 10 read model allo stesso aggregato tutti e 10 vengono ricostituiti così.Questo sempre se custodiamo gli eventi questo è sempre seccusso, io non l'ho mai fatto, il problema poi dell'event sourcing è che devi averci imposto da farlo, le pratiche per conservare gli eventi e di questo poi magari ne parleremo perché è diventato l'uomo esperto di una cosa particolare, è l'uomo dell'evento, è il uomo del momento, più che l'uomo dell'avvento.Diciamo che negli ultimi anni la cosa che si è venuta a creare è che io ho un miliardo di eventi, due miliardi di eventi, sei miliardi di eventi, un trilione di eventi, ma sta roba a un certo punto do me la fico, che devo fare, devo compattare e ci sta una cosa che è una best practice della gestione degli eventi che si è venuta a creare che si chiama event roll up che è una cosa di cui Carmine è particolarmente esperto perché l'ultimo che ci ha messo le mani nel nostro sul nostro roll up è lui e seconda puntata de fila che lo saluto è una pratica che da noi ha implementato il nostro collega Fabrizio Sestito e E' una pratica per cui tu, la spiegazione più semplice è il tuo dominio è la ragioneria di un'azienda, tu a fine anno che cosa fai? Chiudi il libro mastro, prendi le cifre dell'anno prima, senza tutti gli eventi, gli eventi li prendi e te li metti dentro qualche backup, te prendi lo stato degli aggregati, te prendi i numeri alla fine, tutte le somme, li segni sul libro mastro dell'anno 2024 che sta per iniziare, prendi il libro mastro vecchio, lo metti dentro uno scaffale, non lo vedi più e ricominci da un evento, da una base di partenza che sono le somme dell'anno precedente e tu quindi tutti quegli eventi, non dico che li puoi buttare, nel nostro dominio li puoi buttare.Nonostante l'abbiamo implementato in modo che tu possa quantomeno vederli.Nel senso alla fine era il nostro caso e una questione anche cioè il nostro caso in generale una questione anche di performance ok? Se devi ricostruire l'aggregato riavvolgendogli eventi, una cosa è che ne riavvolgi 10.000, una cosa è che ne riavvolgi un milione.Per quanto queste siano cifre assolutamente spannometriche perché magari avete un event store che è super performante e quindi non vi interessa farlo, però diciamo in un caso medio è buono ormai fare questa sorta di squash per ritornare a git e come se stesse squash and commit quando state facendo la vostra PR, insomma, quindi avete sostanzialmente il risultato finale, una sorta di snapshot.Per ritornare giusto così, per completare la cosa del C5RS and sourcing, si può fare, ha un po' meno senso, però in realtà un diagrammino che vi da un esempio migliore di quello che almeno vi ho potuto dare io, è su un microservices.io, immagino che ve lo lasceremo nel link da qualche parte, ve lo ho inviato in chat qui, dove praticamente avete diversi servizi che interagiscono con il vostro servizio e mandano diversi comandi, ok, che generano diversi eventi che aggiornano questo database in scrittura, ok, che contiene tutta una serie di cose e poi in lettura, ok, potete fare una proiezione di tutte queste cose diverse che avete nel layer di scrittura per generare delle viste diverse rispetto a quelle che vi servono.Senza event sourcing può perdere un po' di senso, è come se hai questo buglione dove ci metti la roba dentro e fai le proiezioni, boh sì, no, non lo so.In realtà senza even sourcing per esempio Trento c'aveva tantissimo senso, cioè nel senso a me l'even sourcing piace e quindi io sono un grande promotore dell'even sourcing, però c'è di avere pure il disco rigido dove mettere la 'sta roba, quindi cioè ha dei costi non banali.Se non vi interessa lo storico ma avete la necessità di persistere in scrittura diverse cose da fonti diverse con shape diversa e in lettura aggregarle su delle entità diverse da leggere o da condividere, che vanno, che vanno cross magari tutte queste robe qui, c'ha moltissimo senso.Se non vi interessa lo storico, potete anche anche farlo senza events hosting.Se vi interessa lo storico, in realtà, si apre tutto un altro capitolo, dove si mettono gli eventi e come li conservo questi questi eventi questo è tutto un un troppo picca parte perché perché in realtà secondo me la risposta vera non c'è.Si tra l'altro il problema allora ci sono due cose da dire e la prima è fare un cappello necessario.Qua veramente sponsor, nonostante tutte le cose, toccava il momento shameless sponsor.Io e Carmine lavoriamo a Suse e facciamo con il CQRS e con l'event sourcing un prodotto di monitoraggio e observability.Quindi diciamo che poi almeno le mie esperienze, perché questa è la mia prima vera...Ese, fai observability con l'event sourcing, l'observability di per sé è uno di quei contesti dove si genera una quantità di eventi.Mamma mia, l'e-turkey.E' proprio l'e-turkey.Tra l'altro noi abbiamo avuto questo cliente di cui io non farò il nome così attutelata la sua privacy, perché veramente qui abbiamo avuto questo meeting, era un cliente molto grande che a un certo punto mi ha detto "eh ma qua ha problemi di spazio" e mo' carmi ne ride in botto perchè ha capito "ehm ma qua c'è lo spazio del database è in botto de roba" io ho fatto "regà mo' c'è...quant'è in botto de roba secondo voi?" "è 30-40 giga" ho fatto sì ma a parte che noi abbiamo il nostro fantastico tra rollup, cronjob che puliscono gli eventi morti, vecchi eccetera quindi comunque lo spazio occupato non è tanto, ma poi ragazzi, gli eventi del sistema di observability, sono tanti.Soprattutto perché te li tieni 70 mila anni.Infatti noi abbiamo una politica di retention, abbiamo tutta una serie di cose.Diciamo che in realtà il caso nostro si sposa perfettamente con l'esempio che abbiamo fatto prima perché ad esempio abbiamo un endpoint che colleziona queste richieste che noi chiamiamo di discovery, ok, che arrivano dalle macchine fisiche e la macchina fisica ci invia dei metadati sulla sua esecuzione, non fa la post e dice "ah ok questa unit di systemd è active", ok no, ci manda questo payload enorme, gigantesco, che viene ricevuto da noi e non è mappabile su nessuna entità del nostro dominio, sono dei dati sparsi.Quindi quei dati sparsi vengono ricevuti e vengono generati tutta una serie di comandi, quindi che creano l'host se è la prima volta che quella macchina ti sta mandando quella roba lì, che creano un cluster, se ci sono più macchine che hanno lo stesso tipo di che crea il database se in quel periodo grande c'è scritto che c'è un database.Quindi voi potete immaginare, questa cosa non si poteva fare presto, perché noi non avevamo una risorsa che si poteva manipolare, noi avevamo una roba spuria che dava, che in scrittura, da origine a diversi comandi che creano di versi Aggregati che creano delle entità in lettura quindi Questo qui proprio è l'esempio calzato volendo immaginare questo famoso aggregato che si Si analizza si capisce tutta questa roba pura me l'immagino come un enorme pattern matching enorme batter magic, cioè se poi ti apro il codice in faccia il problema è che pescerà lo schermo qua penso che veramente devo far morire.No pesce lo schermo io devo cambiare il sistema per la dio...quanto mi...si tipo non lo so...aspetta aspetta oh boni boni aspetta oh aspetta aspetta.Ah aspetta ma qua sto su chrome aspetta io.Io pure so su chrome, esatto infatti forse...La sfida sarà raccontare il codice agli amici che ci seguono via podcast.No, no, ma in realtà secondo me si racconta proprio...No, fermate, fermate.Vedi che qua ci avevo aperto il manuale perché ho fatto un bordello e non mi ricordavo niente.Ma adesso io vi faccio vedere questa cosa.e tu dirai ma potevi stream alla finestra? questo è tanto vero se vuoi la finestra ce l'ho pronta io no no guarda, mo ti regalo questo momento di gioia zoom zoom zoom dove stanno i nostri aggregati? zoom zoom zoom dai c'è tutto questo entusiasmo Dai su Trento, subsystems e su subsystems.Mamma mia! No perché abbiamo fatto un mega refactor e la madonna l'ha fatto Carmina a questi giorni perché il suo direttore di rista va sfondato.Sto vedendo un file che inizia con tipo 45 righe di introduzione e di descrizione.di documentazione, questa perché è la doc in line dell'XIR che è molto figa e nel senso che l'XIR quando fa queste cose sembra veramente fatto per fare queste cose e il merito è del linguaggio ma soprattutto del framework cioè il framework, cioè il signor Ben che fa Commanded che è veramente...cioè io gli pagherei una cena Commanded non gira dentro Phoenix è un'altra roba giusto? Commanded è un'altra roba.Tu se vuoi la tua API la fai con Phoenix, ma la parte di 5RS è tutta un'altra parte.È tutto componibile.Qua c'è documentazione, documentazione, qua ci sono gli alias che sono tipo gli import del JavaScript per gli amici a casa.E poi dopo te questa è una macro che ha scritto Fabrizio che praticamente fa questa cosa qua, cioè praticamente definisce un tipo e il tipo è il nostro aggregato in realtà.Il vostro oggetto, i canti dell'oggetto.Praticamente ha un ID suo, un sistema ID, la sua health, una roba tipo un'entity di Symfony.Sì, sì.Io perché Symfony fortunatamente non ce lavoro più, però nel senso questo e poi c'è anche delle cose embedded come aveva detto Mauro prima per cui c'è dei database questo è proprio noi facciamo monitoraggio anche dei sistemi SAP purtroppo e questo praticamente è un database c'è un application che è un altro tipo praticamente dei database perché sono tutti database però fanno cose diverse.Un application dovrebbe essere una roba tipo abbap, queste cose strane.L'application è come se fosse Tomcat, un application server.Sì, è tipo Nginx, però, è un application server, tipo JBoss.E poi come vedete, io questa è una cosa che tento sempre di spiegarla quando parliamo dell'XSeries, soprattutto settimana scorsa ovvero non dirò quanto tempo è passato, soprattutto ieri, cioè Elixir ha questa cosa che è il pattern matching sulle funzioni, per cui quello che il nostro aggregato è letteralmente come ha detto Mauro un mega pattern matching, per cui tu hai tutte queste funzioni che si chiamano tutte execute, però reagiscono, il primo parametro è l'aggregato, subsystem bla bla bla in cui puoi anche matchare delle cose che stanno dentro l'aggregato, tra l'altro.Il secondo parametro è il comando e tu ogni volta che hai execute subsystem è un comando diverso e a seconda del comando succedono delle cose.Qua succede per esempio che se io ho subsystem con subsystem id nil, quindi è nuovo aggregato, non esiste questo sistema nella mia memoria e ho register database instance come comando e ho tutte le cose che stanno dentro il comando e le distrutture qua.Quello che faccio è emettere una lista di eventi e poi queste sono le execute e che praticamente prendono i comandi ed emettono gli eventi e parallelamente se io vado sotto, molto sotto perché il problema degli aggregati è che diventano pure grosso, le apply che sono un'altra cosa, le apply sono quelle che prendono gli eventi e si mettono, cioè emettono praticamente il nuovo stato dell'aggregato.Tutta sta roba è il trucco che viene consumata una alla volta perché se no chiaramente la concorrenza te se porta via.Però il punto è esattamente questo.Tra l'altro posso anche, questo praticamente come si costruisce una nuova strata in elixir con questi punti percentuali e queste cose qua un po' strane proprio come lo stavi dicendo mi è venuto un altro modo per rappresentarlo alla fine l'aggregato diventa un event listener che reagisce a una serie di eventi che sono comandi però considerati, è un command listener e ha uno stato e alla fine lui spara gli eventi e tu ti attacchi agli eventi per quelli che ci vedono da video noi faremo, vi faccio vedere pure in proiettori a questo punto ma infatti un aggregato in commanded è come se fosse un event handler da una parte ed un command listener è un event lander perché reagisce agli eventi e ha uno stato da un command listener ma professore, ma momento code review live su twitch database projector c'è database register ma perché dei read model li abbiamo messi qua dentro? insieme ai projector? perché lo fa anche il signor Ben Smith ah ok, perché praticamente lo storico di questa cosa di cui stiamo parlando è che noi abbiamo preso tutta sta roba e abbiamo fatto refactoring della madonna perché c'eravamo un director Iri che era sfornato, non si capiva niente e abbiamo fatto proprio buy the book perché sta roba se non la fai by the book alla fine d'accorgi che la mia è quella sbagliata esatto e quindi adesso mi stavo chiedendo ma quindi i read model li abbiamo messi vicino qua.Sì, il signor Ben Smith fa un solo file, fa un file che è il read model con lo schema con le project data.Ah vabbè ok, meglio così.Insomma meglio così e quindi qua dentro noi abbiamo questo è un projector che io da un'altra ho fatto eccetera e praticamente io ho questo, ho che project database registered, ho questo qua, queste qua pure sono tutte project se vediamo, database registered, ho la mia funzioncina che si prende già da sola perché me lo dà il framework, quello che si chiama Hecto Multi che praticamente è Postgres, è un affare, e praticamente io quello che vado a fare è database read model, mi creo il mio change set, che è esattamente il modo di fare una proiezione.Quando viene fatta la proiezione? Adesso, qua.Adesso, qui.Si, nel momento degli eventi.Quando viene dispiacciato l'evento in maniera asincrona.Quindi viene creata una proiezione, cioè viene aggiornata la proiezione ad ogni evento? Si.Si.Ok.Perché in realtà storicamente io ho visto situazioni dove in realtà la proiezione veniva generata periodicamente e su quella proiezione...questo è un trick...sì esatto la proiezione veniva aggiornata periodicamente o almeno io facevo così con la disponibilità aggiornavo periodicamente la proiezione, la datavo e poi ci applicavo su quella proiezione gli ultimi eventi arrivati appunto subito dopo che potevano essere un giorno o due giorni e a quel punto avevo un aggregato, quindi il famoso event listener con lo stato, avevo l'aggregato sempre bello fresco.Allora in realtà qui funziona in maniera diversa, nel senso che quando l'evento viene emesso ci ci sono i proiettori che sono inascolti e fanno cose, però in realtà per motivi di performance e di consistenza anche, tutto ciò, per non scendere nei dettagli del framework, una serie di operazioni di proiezione viene effettuata in batch in una transazione, quindi non a rigore di un giorno, due giorni, tre giorni, però vengono effettivamente fatti in match poi dal framework commanded, ma in realtà è come se venissero fatti ogni volta che...Con le multi, no? Cioè il motivo per cui voi vedete questo multi qua e questo multi qua, praticamente perché noi quello che facciamo è dispatchare un change set che è come se fosse una insert, Però, ho un update, però praticamente poi lui sotto c'ha un worker pool, cioè è la classica cosa che fate dentro ogni applicazione dove voi non è che fate, cioè voi credete di fare una insert, voi amici a casa, ma non la fate mai la insert, sotto c'è un connection pool, un worker pool, sotto qualsiasi libreria di gestione database, orm, eccetera, che si prende questa roba e quando ha tempo la fa.Quando ci sono connessioni libere, connessioni utilizzabili.Infatti la cosa figa di fare un ORM, o un ODM o un che ne so, è che poi i test di quella roba sono interessanti.Se tu vai a leggere i test di che ne so, me ne dico uno a caso di Mongoose, ma pure i test di Hecto e in Elixir sono clamorosi perché vedi tutta la cosa che si sono inventati loro per rendere la sync ai tuoi occhi e anche nei test.Ale puoi stoppare lo sharing sennò mi va in palla una funzione che mi serve proprio per il metodo di conoscenza.Ah niente scusa.Cosa? Domanda interessante.Pensavo a una cosa in realtà.Abbiamo un po' visto come funziona il CQRSS, quindi Command Query divisi.abbiamo spesso una serie di eventi abbiamo però una memoria che spesso cresce, un event store che spesso ha bisogno di essere performante abbiamo detto che esistono dei trucchi ma oggi in realtà quali sono le tecnologie che vengono utilizzate per storare gli eventi? allora voglio dire una cosa prima che gli eventi sono immutabili non si cambiano.Uno va sopra l'altro.Questa cosa è importante, anzitutto è un pilastro proprio dell'architettura in generale, ma soprattutto che cosa significa? Che nel store metteteci le cose che ci potete mettere, perché non ce le togliete.quindi se fate nero non utilizzate un sistema e soprattutto tenete conto che se avete delle informazioni sensibili che va ad esempio non lo so, vi state registrando i vostri utenti Ok? Quella parte della registrazione, fatela crud, che poi la modificate, la anonimizzate, ci mettete l'asterisco, non ha senso farla con l'event sourcing.E infatti noi non la facciamo così.Fai la registrazione, ce la dà bella user, se fai il login, il recupero passo, tutto quello che serve.Perché una roba lì può essere modificata.Oppure se decidete di farlo per qualunque motivo con l'event sourcing, affidatevi ad un servizio esterno che vi gestisca esattamente l'identità, un identi server.Quindi nell'event store c'è lo user, c'è lo userd, non c'è la mail, non c'è il nome, non c'è il cognome, non c'è il codice fiscale, non ci mettete i numeri delle carte di credito, che non si possono mettere a prescindere, ma ho visto troppe persone che ci hanno mettuto le carte di credito nel database, insomma.non potete modificarlo e se andate sul vostro editor e lo martellate per modificarlo tanti side effects inaspettati si possono verificare no no questo è giusto infatti la cosa è sempre cioè secondo me l'importante quando si fa un'applicazione in 5rs è mappare che cos'è il dominio, fare il dominio in 5rs e solo il dominio e il resto farlo in altri modi e si può fare tranquillamente perché se no fate la registrazione degli utenti in 5rs e morite al secondo giorno del vostro side project.Esatto e questo era proprio l'altro punto di cui volevo parlare.Io vi ho detto che in realtà ho sviluppato una parte del progetto del mio famoso booking quando avevo l'azienda.Avevo letto un bellissimo white paper sul CQRS, gasatissimo.Ho detto "ma sì, faccio tutto così".Appena ho provato a fare, ed era proprio la registrazione di utenti che era un pochino complicata con del team, corporation, c'erano delle holding che contenevano corporation, che contenevano team, quindi già quella parte iniziava ad essere complessa.Quando tu dovevi fare avevi già fatto la crude delle holding, delle corporation e dei team erano già passati quattro mesi.Perché credetemi è diventata una cosa assurda.Per cui a quel punto butta tutto sul cestino.All'epoca era Symfony il framework.Quindi usavi BluF.No, fatto a mano dentro Symphony.E tra l'altro Symphony aveva un bel sistema event interno che era fatto bene, quindi si poteva fare.Serviva un po' di disciplina, ma si poteva fare.Lo ricordo ancora con un certo piacere e dolore.Non so se avete presente quelle cose che generano piacere e dolore.L'event sourcing, il CQRS là dentro era così perché in realtà oltre a quello stavo mettendo il domain driven design e l'hexagonal architecture tutto insieme, no? E se ti vuoi fare del male unisci questi tre concetti per la prima volta insieme in una nuova applicazione e prova a essere effective.Probabilmente non lo sarai, a meno che non hai un team di 30 persone che l'hanno già fatto, non sarai effective.Oppure, e qua momento pubblicità, oppure ti prendi un libro, a meno che tu non vuoi fai l'exeer, a quel punto ti prendi un libro che si chiama "Building Conduit" di Ben Smith, quello di Commanded, e tu ti prendi "Building Conduit", te lo leggi, ci stanno alcune cose che non tornano perché è fatto con la versione vecchia di Commanded, però lui applica tutte le cose, ti insegna a fare un blog e ti fa pure la registrazione degli utenti, tu ti devi solo copiare i codici.E c'è anche un progetto più nuovo che è quello che abbiamo copiato noi per The Best dove però non c'è nessun tutorial ed è molto più complesso.Qual è? È una roba su Strava, tipo...Ah, sì, praticamente sempre Ben, ho capito qual è, ha fatto con Commanded, ha fatto questa applicazione che gli fa tipo la leaderboard delle corse che si fa a lui su Strava e praticamente che usa sempre Commanded, ha sempre un sacco di roba dentro che usa e quindi dall'app potete copiare.Copiare è molto bene perché vedi già delle best practice.Purtroppo la seconda...noi ci siamo fermati alla prima cosa che volevo spiegare prima e adesso spieghiamo la seconda.CQRS è un paradigma che nonostante gli anni passi continua a essere sempre molto giovane, per cui ci stanno delle cose tipo il rollup, delle best practice che sono venute fuori l'anno scorso, cioè non l'anno scorso, però il rollup non esiste da tanti anni e prima la best practice era prendersi tutti gli eventi e basta, perché nessuno c'aveva ancora mai avuto quel problema headscale, dove hai i petabyte di eventi e dici "ma io che ce faccio?" e quindi il problema di questo è che non è che trovi le risposte su Stack Overflow, come si fa questa roba, pure perché è roba architetturale e molto spesso è roba del dominio, quindi a meno che non stai a fare, cioè non è che trovi su Stack Overflow, che io e Carmine si alziamo la mattina e andiamo su Stack Overflow e troviamo quello che sta a fare l'app di monitoring e observability e che ci dà una mano, purtroppo c'è tanta architettura in mezzo, c'è tanta giovinezza del paradigma in mezzo e c'è in mezzo il fatto che ogni persona lo fa un po' come vuole, col database che vuole, con le cose che vuole.Per tornare alla domanda di Mauro, a cui io non credo che abbiamo risposto, le tecnologie usate per storare gli eventi ad oggi sono.Io ti parlo da me.Allora la prima è EventStoreDB, che è un database scritto da Greg Young in C# che ha fatto apposta per gli eventi e per il CQRS e per l'event sourcing.L'altra cosa che si usa per storare gli eventi è, indovinate un po', postgres e noi usiamo postgres.Ma gli eventi di per sé hanno una natura che è un po' step back.Voi avete una tabella per tipologia di evento o lo utilizzate in blog mode? No, noi utilizziamo rigorosamente la blog mode nel senso che io non so se poi c'è qualcosa sotto per fare delle cose strane però il package dell'Xe...perché Ben Smith è autore decommanded ma poi commanded è diviso in sottopackage e un package si chiama proprio event store e il package di event store ragiona così.C'è un adapter che ha scritto Fabrizio Sestito sempre per event store DB, però il ragionamento è sempre blob mode, di base.Ma è blob mode in realtà per un motivo preciso, nel senso che è blob mode ma per come funziona commanded hai una grossa tabella con dentro tutti quanti gli eventi che non è intanto che una riga con alcuni metadati e il JSONB puro dell'evento, dopodiché questi eventi sono collegati tramite una relazione SQL a GStream, che sono la collezione degli eventi di ogni singolo aggregato.Quindi non hai la divisione per tipo di evento, anche perché quello avrebbe un po' poco senso, ma hai la divisione per stream, e quindi per aggregato.Tu sai che l'aggregato o prenotazione con i D, X, Y, Z ha uno stream che nel database è un sotto insieme degli event che ci sono nell'event store.Ovviamente questo tipo di modellazione è quella che ha scelto lui, quello che ha fatto insomma il pacchetto, il signor Ben Smith, però ci sono altri altri altri modi per farlo.Il fatto però di avere una tabella che è un blobone con tutti quanti gli eventi dentro vi dà più flessibilità perché a quel punto se volete fare un raffinamento non fate nient'altro che un'altra tabella che ha delle relazioni con quegli eventi.quindi a quanto ho capito in questi anni così che l'Event Store più lo vai semplice e meglio viene.Questa implementazione con Postgres che è molto complessa se vedete le migrazioni, ma le posso garantire che sono otto migrazioni e sono molto molto capibili, le incollo qui in chat per chi fosse interessato, sono insieme di tabelle, trigger e pg notify così secco pg notify bello Parliamo un attimo del sistema di notifica invece di pg notify Che è una roba che mi gaza tantissimo da quando la video utilizzata in super base nel senso in realtà la gestione degli eventi perché quando io penso a un sistema event sourcing forse in modo limitato mi viene da pensarlo in modo monolitico quindi mi immagino che sto monolita ok voi per la mia esperienza io ci ho fatto monolita cqrs e gli eventi aspetta ok ho avuto una epifania in questo momento.Ha craccato il cervello si si si no no fondamentalmente in molti casi noi dispacciamo gli eventi nel contesto della nostra applicazione quando invece dobbiamo scalare abbiamo bisogno di dispacciare gli eventi in modo diverso talvolta si usa Rabbit altre volte si usa Kafka per cose un po' diverse ma PG Notify lo usi praticamente per fare questo? quello che faresti con Rabbit? quindi io dispongo un evento...No, io no, cioè nel senso Pigino che lo usa lui internamente Lui usa lui internamente perché tu considera che essendo che ogni aggregato è un processo, è un attore diverso e li devi notificare tutti sono tutti quanti subscriber perché tutti possono essere potenzialmente interessati ad un evento che tu ci stai mettendo dentro cioè quindi nonostante sia una applicazione monolitica il fatto di modellare ogni singolo attore interessato ad un evento come un processo, te la sta rendendo comunque distribuita, seppur nel contesto di uno stesso nodo.E il fatto di farlo in Elixir con la BIM puoi metterci più nodi, ma è sempre trasparente, quindi quel sistema di notificare un processo funziona su un nodo come su 15 perché è l'attuale Xero.Purtroppo sì, cioè nel senso questa è la parte un po' specifica di questa cosa.No perché io non venendo da Xero, cioè io mi immagino che l'evento viene dispacciato sul RabbitMQ, sul gestore di code della situazione, io ho uno o più micro/macro servizi che un micro servizio può gestire che ne so un un aggregato specifico può essere uno degli n microservizi che gestiscono quell'aggregato specifico, l'evento si attaccano al bocchettone del sistema di code per cui non ho bisogno di un pg notify in quel caso.Oppure hai bisogno di un solo pg notify, nel senso hai un un trigger che quando scrivo mail dalla base ti chiama l'unica routine che è il router di rabbit quindi la tua applicazione che prende l'evento e la manda sulla coda giusta.Tipo van out E voi questa cosa la fareste fare a postgres al post di fare la livello applicativo? Eh non hai comunque...se non la fai fare a post significa che hai bisogno di un solo attore che scrive sempre lo scaglio e scopriamo puoi scrivere in modo parallelo su postgre l'evento e dispacciarlo in modo che hai da una parte lo storage dell'evento dall'altra il trigger che poi ti attiva i vari con i anni perché l'evento devi sapere che è stato cioè che è tutto a posto per poi avere la projection per esempio la consistenza c'è per questo si tende a delegare più al più al db perché il db ti da diverse garanzie che replicare al livello applicato però il db non scala, c'è quel problema? no no il db non scala però tu quella roba là la fai dentro la projection per esempio noi abbiamo live in store che è fatto così noi adesso con PG Notify stiamo parlando di un internal del live in store non è una cosa che facciamo noi con qualche codice nostro, è una cosa assolutamente interna dell'Ingress Store, però poi abbiamo altri servizi all'interno dell'applicazione che non fanno parte della big picture, ma non fanno parte del dominio di questa applicazione qua che abbiamo visto, quei servizi là il sistema a eventi tra virgolette lo facciamo Rabbid.Strettamente parlando noi abbiamo sia PG Notify che Rabbid.Nel senso noi abbiamo l'event store che fa una cosa, poi però tutti gli altri diciamo bound codecs.La comunicazione intraservizio si fa con Rabbid.Ma quindi quando succede qualcosa, c'è un evento, viene dispatchato, quindi il comando dispatcher dice "Hey mondo è successa questa cosa" fondamentalmente è quello che succede.Aspetta di "Hey mondo" quando succede qualcosa dovi? Ok, voi non avete un unico event bus quindi? No, non c'è proprio l'event bus, nel senso che c'è solo nel contesto delle cose che si attaccano all'event store.Questo trovo che è il PHP, perché GoSymphony te serviva RabbitMQ per mandare cose e ricevere le da solo.No, che cosa fa PgNotify? PgNotify notifica e viene mandato un messaggio nella mailbox di un processo airline, quindi non c'è bisogno dell'event bus.quindi voi semplicemente scrivete sul database e quel processo dice "Dream, guarda è successo questo" e voi praticamente state delegando tutta questa reattività al database alla virtual machine sì vabbè la virtual machine rimane in ascolto e PG notifica e quindi è come uno scambio di messaggi tra processi ok e invece tutto il resto delle chiamate tra aggregati vari e tra servizi e tra sistemi lo fate però quello sta fuori dall'event source, dal concetto di event source, cioè semplicemente comunicazione tra microservizi in questo caso.Noi abbiamo altri microservizi che non usano il CQRS, questo è il fatto e quindi abbiamo che usa, so crude cioè normale però hanno delle cose comunque sono reattivi a livello hanno un bocchettone di Rabbit, se hanno degli eventi della web app da Rabbit io faccio broadcast e poi quelli fanno la loro roba.Sì che poi in realtà ecco è una cosa che sembra assolutamente complessa stiamo parlando di ipc che di solito è una roba diciamo...stiamo parlando di roba che...stiamo parlando di internal, cioè il fatto è che noi siamo parlati un'ora dai di internal è come se parlassimo di un'ora di come è fatto fastify cioè certo che ti sembra poi quando lo usi è una cazzata In realtà se va a vedere il codice dell'aggregato che è questo qui, non è nient'altro che un genserver, quindi tu chiami questa cosa che a te sembra sincrona come una chiamata a funzione ma sta inviando un messaggio ad un processo, quindi nel senso è tutto molto molto trasparente.Il fatto che noi diciamo ci sono processi che sono sponati e tu chiami, il messaggio, molto molto trasparente.Il nostro discorso è molto condizionato dal contesto Erlang/Elixir.Sì, sì, assolutamente.Se volessi farlo in un altro contesto, dovresti farlo in un modo totalmente diverso.Anche il fatto di tenerlo in memoria come un processo.E' una cosa che permette l'XIR di farlo.C'è un framework eccellente per Ubi, perché ho visto, cioè le API sono eccellenti, poi non so se funziona bene.Però non so se c'ha le stesse cose dell'XIR, se se dia negli aggregati in memoria, cioè è tutto molto specifico.Io ricordo che con Symfony persistevi tutto.Persistevi tutto perché PHP non c'ha Lifecycle, finisce la chiamata e muore, quindi come fai? Io persisto per tutto.E lo persisti su un Redis.E ogni volta che parlo con qualcuno che fa PHP dice "Vabbè ma io ce l'ho la memoria, c'ho Redis".Certo, a me non è bashing a PHP, che PHP è fatto così.Invece può essere che ho degli amici che hanno fatto un create di Rast che si chiama tipo mini-cqrs, un signore che si chiama Andrea Pavoni.e che nel senso, una persona che conosco, ci ho lavorato tra virgolette insieme in altri contesti a Prima.it, lui ha fatto Secret The Rust che è mini 5 RS, penso che anche lui sia aggregato in memoria, non lo so, però sono sempre...Domanda, e poi chiudiamo perché abbiamo una hard limit.Sì perché io devo annaccenata a miso, era scusa, è colpa mia.che è il famoso riso con le patate, non si...buono mamma mia, esatto guarda che bello questo, bravo Gà ci siamo girati in chat, eventuali che è un framework 5RS per ES e anche per RUST ma lo fareste mai 5RS in RUST? non ho mai provato, io ho delle opinioni molto forti su sta roba su sta roba, come dicevamo ieri con Andrea, a volte nell'XIR è più facile prototipare perché non essendo tipato, non essendo c'è nessuna supercazzola di correttezza formale del codice, la prototipazione è un po' più facile.Dall'altro canto, io sono appena tornato da RustLab e c'è stato un signore che ha detto "Prototipare in Rust è facilissimo, basta che dai la per compilatore", che è altrettanto quindi non so dove sta la verità.Io personalmente, te devo dire la verità, mi farebbe un sacco gola dal punto di vista della sperimentazione, però io so due anni e passa che lavoro con Commanded, è un framework della madonna, complimenti Ben Smith, c'è veramente...ci ho fatto anche in side project e il side project è finito a essere deployato su uno dei i miei server, quindi ho portato a compimento con tutto che 5 REST si fa perdere una marea di tempo a modellare il dominio giustamente.Io purtroppo so, ho il bias che per me Commanded è la miglior cosa da quando l'uomo non vede il cavallo, come direbbe Gigi Broglie di Bonanni.Altra domanda, io vi svelo un segreto, provai a fare un frame per il primo periodo che iniziai lavorare in e-reform dove c'era appunto la dottrina Fastify, per fortuna che c'era la dottrina Fastify all'Ugere.Iniziai in uno dei miei side project era fare un plugin di Fastify che supportasse il il CQRS.In realtà c'era già qualcosa che aveva della roba, però quando ho visto tirare dentro concetti come la dependency injection, le annotation, cose di questo tipo, mi è venuto il freddo e ho detto no forse anche no.Domanda perché non è così così noto in javascript il cqrs come in altri linguaggi per esempio in php c'era il periodo dove si parlava solo di cqrs e vs.Si si è stato un periodo in cui in hootsuite l'abbiamo fatto pure noi esatto e allora io Io vuoi la mia risposta onesta, Alessio Biancalana style? Che Node fa cagare.Cioè nel senso, Node non è concepito per stare su tanto tempo.Tant'è che c'è una risposta famosa di Matteo Collina, che era tipo, se stai facendo un'applicazione Stateful con Node che ha tanta complessità, stai a sbagliare, perché devi tenere le cose piccole e devi mannare cose bla bla bla.Io sinceramente non so d'accordo con questa cosa.Io non penso che un runtime di JavaScript non dovrebbe sfidare lo status quo di queste cose qua e dovrebbe invece migliorare le sue prestazioni andando avanti nel tempo.Quindi quando c'è la BIM è fatta per sta sola e sempre.È architettata in questo modo.Ci sono satelliti buttati una volta di cui è stato fatto il livepatching a caldo della la memoria del codice e non sono mai stati fatti a terra.E quelli vanno giro alla BIM.Secondo me Nod dovrebbe avere la stessa aspirazione, perché è possibile farlo, l'hanno fatto, e quindi io non vedo perché Nod non lo dovrebbe fare.Però lo stato attuale di Nod è che a un certo punto ti schioppa per vari motivi.D'altra parte non mi sento nemmeno debbiasimo agli sviluppatori, perché sicuramente io farei un lavoro peggiore.Però il problema è che secondo me su Node non c'è tanto fermento su 5RS per questo motivo e secondo me è male perché se l'hanno fatto in PHP famolo pure con Node.Anche perché poi c'è Redis per gli eventi quindi quello schiomba un po' meno.Secondo me c'è anche una questione proprio di trend, nel senso Nord ora vive comunque un periodo in cui si fanno delle robe veramente fighe.Abbiamo visto qualche qualche puntata fa con Paolo Milo, ad esempio, che proprio anche lì si sta ridendo e ha fatto "Rust".però ho detto ok, però nel senso ora il trend di node è della single page, no, nemmeno più la single page, è next con il SQL dentro, il frontend monolibrico Ci sono comunque più trend che interessano la vera e mia cosa probabilmente ad esempio se andiamo già su C, C#, Java, ma anche PHP, che magari sono stati in contesto più "enterprise" dove "enterprise" è una parola brutta, probabilmente c'è più interesse.Ad esempio in Java c'è "eventweight", che è un framework che permette di fare...- Bello cazzuto, sì.- Non lo so, probabilmente è pure una questione di trend del linguaggio.- Sì, è strano perché pure io ho cominciato a farlo con Node, cioè nel senso io stesso guardato la roba dei nod e non mi convincevo.E' la stessa cosa e personalmente da programmatore che ha fatto un sacco di JavaScript.Io ne ho vinti un paio di framework per fare CQRS.Cioè per me il CQRS era...deve essere una cosa facile dove tu ci metti dentro l'aggregato, i comandi e gli eventi e deve funzionare tutto.E' comando ed è così.Tu a fa il setup ci metti una sera ma poi quella cosa non la butti più giù.A me per quello mi piace perché...I nostri amici ascoltatori che commentano in chat "eh ma c'è nest che fa il CQL nest" prendete nest e cancellate i node modules.Spazio.Che è nest? Ah nest è framework, si va bene.Prendete nest e cancellate i node modules.E gira uguale.E liberatevi da questa cosa qui.Vi ripeto che qua in Francia tra Symphony e Nest non si parla d'altro.Madonna che tali.Assolutamente, perché Nest è in Java e in PHP.Anche perché sono tutti e due francesi, tra l'altro.Sono tutti e due in Java e in JavaScript e in Java e in PHP.Assolutamente.Ma nel senso c'ha perfettamente senso per alcune cose, ma io vi posso garantire che a livello di...cioè è bello onesto perché sembra grosso ma è una merda proprio come fa a utilizzare cose del genere.No ma questo è terribile, Gildragon DTO ma che stata scherzavo.Ma ragazzi ma fatelo in Java su una virtual macchina seria.È tutt'è uguale, secondo me se Comic Code...io so avete degli esempi in TypeScript, secondo è uguale.Gira uguale.Bold opinion delle sette e mezzo.Ho vissuto contesti dove ti salva solo Nest.Mamma mia Mauro, cioè veramente.Ho vissuto contesti dove ti salva solo Nest.Contesti dove se lasci la libertà di dire usati un Express o un Fastify e montati plugin ci vedi mostri.ho visto programmatori che sanno programmare solo quando hanno un service bus, una notation per fare la rotta, uno rm e devono definire il service e annotarlo per avercelo dentro perché non devi essere un programmatore javascript ma devi essere un programmatore nesta che molto più semplice che essere una madre si io purtroppo la la la sticella sia così e sono tutti sono tutti quanti allo stesso livello perché quel punto è il framework che ti chiedi chi è una cosa cattiva a me a me piace phoenix race lara ok figuriamoci ma sono comunque cose che sono inserite in un cesto contesto modulare e veramente naturale proprio e prende già scritto e dirò che non ci ho capito niente di java scritto negli ultimi 15 anni boom next class aperta e chiude class injectable ragazzi fate angular e java per fare l'inversion si devo dire che se fai angular e java prendi java prendi graal vm e spring boot una bomba, una paura, si si, Java ultime versioni è una bomba non vi fate del male che tra 5-6 anni NEST lo utilizzate voi e i consulenti di non videogi che vi avranno da aggiustare, i nostri migliori talenti, ragazzi, lo introduco io come hard limit il momento del paese dei palocchi, Vai con la sigla! Il momento nel quale condividiamo con i nostri guest e i nostri host e oggi solo host un libro, un film, un video, un talk o qualunque cosa abbia catturato la nostra attenzione possa essere utile condividerlo con la nostra comunità e allora...vai con la sigla! Vi conduco nel paese dei balocchi! Ah, il paese dei balocchi! io vorrei portare la dentiera camminante degli anni 80 della nostra città non so se l'avete conosciuta ragazzi io vi chiedo avete qualcosa da condividere con noi? allora, adesso te lo prego il balocco perché non ci siamo messi d'accordo prima e adesso mando in crisi Carmine siccome il 5RS viene menzionato qua dentro Vi consiglio ancora una volta "Designing Data Intensive Applications" di Martin Klepman.Ti odio.Perché? Eh, ma perché quello è il balocco.Quando si parla di CQRS, cioè il CQRS viene menzionato tipo alla fine del libro e dice comunque tutto quello che io ho detto lo fanno tanti framework CQRS.E' veramente un libro della madonna quando si parla di queste cose Che altro vi posso consigliare? Vi posso consigliare...Come balocco, guardate, vi porto Phoenix e Commander, cioè veramente date una possibilità a Linkseer quando vi capita, perché secondo me è un bel giocattolo Io invece vi porto il corso di sistemi distribuiti di Martin Kleppan che è gratis su YouTube sono 12-13 reazioni che sono assolutamente interessanti.Per esempio il corso di sistemi distribuiti che fate alla magistrate del primo anno dove fanno le epoca kit lo buttate e vi vedere quello.È più lungo ed è fatto meglio.Io in realtà non ho un balocco perché altrimenti non ce l'avrò per la puntata che registro tra circa 45 minuti.Io devo andare a comprare pesce.E quindi nulla.Io ringrazio nuovamente Carmine e Alessio per aver fatto questa… questi pensieri liberi su sul CQRS.In realtà CQRS, Domain Driven Design, Event Source, ce li abbiamo messi tutti mischiandoli un po' a calderone ma questo è il nostro modo di essere, il nostro modo di vivere, il nostro modo di chiacchierare davanti a una birra ed è così che ci piace ed è così che continueremo a essere.E' arrivato il momento di ringraziare i donatori di questa settimana, le persone che si fanno carico di Gitbar e fanno sì che ogni settimana possiamo arrivare con un nuovo episodio.Questa settimana abbiamo tre donatori che ci supportano, vi ricordo che potete donare direttamente dalla pagina supportaci sul sito www.gitbar.it oppure potete farlo attraverso il value for value attraverso appunto una donazione lightning potete supportarci con uno stream di satoshi mentre ascoltate l'episodio oppure con un boost con messaggio allegato.Bene ma vando alle ciance, coloro che dobbiamo salutare sono quelli che ci hanno preso sulle spalle e hanno fatto in modo che parte dei costi di github potessero essere insomma in qualche modo sostenuti.Vi ricordiamo che Gitbar è gratuito ma non senza costi.Noi lo facciamo con tutta la nostra passione però abbiamo un gozziliardo di abbonamenti di robe da pagare, da sostenere, quindi se vi fa piacere far supportarci, se volete prendervi carico in modo che Gitbar possa continuare a vivere a lungo, beh, il modo per farle è appunto con una donazione.Abbiamo diversi donatori, il primo è Fausto Quattrone e Antonio Lanzolla che ci invitano rispettivamente tre birre ognuno.Abbiamo poi Brian Azzori che ci invita una birra, quindi io direi che a questo punto possiamo alzare il nostro calice virtuale e brindare alla salute di Fausto, Antonio e Brian.Grazie.Detto questo io ringrazio nuovamente, ripeto, Carmine e Alessio e vi do appuntamento alla prossima settimana ricordandovi che i nostri contatti sono info@gitbar.it @brainrepo su Twitter.Il gruppo Telegram @gitbar sullo socialite telegram preferito vi aspettiamo mi raccomando e abbiamo anche il canale youtube mi raccomando iscrivetevi se non l'avete ancora fatto cliccate sulla iscriviti e sul campanaccio detto questo vi diamo appuntamento alla prossima settimana ringraziando fisco zen che ci ha sostenuto e che mette a disposizione uno sconto di 50 euro per il primo anno di sottoscrizione.E' una consulenza, una prima consulenza gratuita senza impegno.Trovate tutto nelle note dell'episodio.Alla prossima.Ciao ciao! Siamo noi che nonostante il deploy fallito, l'Asia in rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.[Musica]
