Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio.La temperatura ormai tende a salire sempre di più e le nostre unità di birretta aumentano.Ma oltre alla birra oggi vi stiamo portando un contenuto veramente interessante.Lo faremo con un ospite.Tra l'altro devo dire che oggi non sono solo con me, Carmine.Ciao Carmine! Ciao a tutti, oggi sono anch'io a dare il mio contributo di pochissimo valutore.Insomma, un po' come il mio contributo, solitamente infatti sono i nostri ospiti che portano del contenuto di valore ed è per questo che ogni settimana abbiamo un amico che ci viene a trovare.Prima però di presentarvelo, il mio compito ormai un po' rompi scatole, è quello di ricordarvi nostri contatti.Info@gitbar.it via email o @brianrepo su Twitter è il modo più arcaico per contattarci.C'è un modo un pochino più frictionless che il nostro amatissimo gruppo Telegram che potete trovarlo come Carmine? Potete trovarlo su Telegram, si chiama Gitbar, il nostro gruppo è Gitbar Podcast e siamo quasi 400 persone e sono accettati tutti, junior, senior, tecnici, non tecnici, venitevi a fare una chiacchierata con noi, anche perché nel senso ci sono solo versioncine di un certo tipo su YouTube, quindi vi state sicuramente perdendo tanto.Tanti flame e tante cose belle.Infatti per chi non si fosse ancora iscritto, ho registrato mi sa troppo di anni 80, per chi non si fosse ancora iscritto mi raccomando facetelo perché è un modo per vivere la community di Gitbar e Gitbar in quanto bar per gli sviluppatori.Però abbiamo parlato anche troppo e credo sia l'ora di fare le dovute presentazioni.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Abbiamo con noi Alessandro Minoccheri, software developer in Flowing.Io so che Alessandro fa tantissime cose per cui chiedo direttamente a lui di presentarsi.Ciao Alessandro! Ciao a tutti e vi ringrazio tanto dell'invito che è veramente stato molto apprezzato perché vi seguo veramente tanto perché è sempre interessante ogni volta, ogni episodio regala sempre qualcosa, emozioni e valore e tutto, quindi vi ringrazio veramente tanto.Come come diceva Mauro, logicamente sono un software di vita, lavoro principalmente in PHP come linguaggio, però non disdegno altri linguaggi tra Java, Kotlin, ma anche la parte frontend come React, Vue, senza tanti problemi perché alla fine è quello che penso che il linguaggio non dobbiamo essere troppo focalizzati su qualcosa, ma dobbiamo essere in grado di espandere le nostre conoscenze e alla fine una volta che uno conosce pattern e test, non dico che sia semplice, però diciamo che ne hai già della fatta.Oltre a questo sono il founder e coorganizzatore del PHP user group Romagna, che era un meetup fisico, ormai siamo entrati online anche noi, ma torneremo fisici in teoria.Detto questo, sono un amante dell'open source, sono un maintainer di alcuni progetti, in questo caso in PHP, perché credo che l'open source possa veramente aiutare le persone a migliorare le proprie skill e a condividere nuove tecniche, dubbi, o comunque avere quella crescita in tanti ambiti con persone con le quali magari non potresti mai lavorare.invito veramente tanto a contribuire all'open source perché è veramente un gran bel mondo.Detto questo direi che come presentazione oggi è tanca abbastanza.Come oggi più che altro su questo talk, su questa chiacchierata che dobbiamo fare è interessante il motivo per cui sono venuto qui perché è un argomento che ho diciamo provato a spingere in alcuni talk eccetera e e tutte le volte ho avuto sensazioni diverse, domande diverse e tanti spunti interessanti, quindi è stato veramente un piacere oggi parlarne qui magari.Vediamo un pochino cosa riusciamo a estrapolare perché ci sarebbe veramente tanto da dire, ammetto.Una volta ho detto questo argomento qui si fa in un quarto d'ora e tutte le volte ci dilungavamo per mezz'ora e ore.Sì, è un argomento molto interessante, ma sveliamolo pure.Oggi parliamo di architetture esagonali.Solitamente siamo abituati, o perlomeno io sono abituato, a programmare con il martello.Quindi vedere delle architetture così ben strutturate, in qualche modo, ci fa bene.Il concetto di architettura esagonale non è una cosa che risale all'altro giorno, no Alessandro? Se ne iniziò a parlare nel...ho fatto una piccola ricerca, adesso mi faccio un picco di questo, no? Si iniziò a parlare nel '92 con il Boundary Control Entity Architecture da Ivar Jakobsson.Poi se ne riparlò nel 2005, quando si introdusse il concetto di architettura esagonale.Seneri parlò nel 2008 parlando di architettura a cipolla, Onion Architecture, e poi è arrivato Uncle Bob, lo zio più chiacchierato dell'IT, che l'ha riportato in auge nel 2011 con il suo Screaming Architecture e Clean Architecture.E allora la mia domanda è...Che cos'è l'hexagonal architecture, con poi tutte le sue declinazioni e perché tutti questi nomi? È interessante come domanda perché ognuno ha la sua accezione, ha le sue piccole differenze, ma alla fine il concetto è sempre lì.Fondamentalmente è stata inventata e pubblicata nel 2005 da Alistair Cockburn principalmente.Per quale motivo? per tentare di disaccoppiare i vari componenti per avere un qualcosa di disaccoppiato che ci permetta di tenere le nostre applicazioni in vita per tanto tempo.È un pattern architetturale.Quindi poi ognuno ha dato l'onion architecture, clean architecture, ma bene o male il concetto base è quello, cioè tenere disaccoppiati i vari componenti, i vari layer.Poi è vero, ci sono tante piccole sfumature, ma secondo me l'importante è il cuore, avere questo disaccoppiamento che quando io ho iniziato a lavorare, diversi anni fa, mi dicevano "si, devi disaccoppiare il codice", io dicevo "ma cosa vuol dire disaccoppiare il codice? A me non sembra che il mio codice fosse disaccoppiato, non capivo bene cosa significasse".Poi piano piano ho capito tutti i vari vantaggi, tutto quello che ne consegue, soprattutto sbattendoci la testa.Quando poi sbatti nel problema dici cavolo, sono arrivato a questo punto, vedi, se avessi disaccoppiato il codice, ecco cosa vuol dire disaccoppiare il codice e lì ti si apre un po' la mente, hai un po' quello scatto che dici cavolo, se l'avessi fatto mi sarei salvato da tutti questi problemi che sto avendo.Attualmente è un tema molto in voglia, nonostante come ho detto se ne parla comunque dal 92, è tanti anni, attualmente in Flowing stiamo vedendo diversi progetti che hanno problemi, non dico di questo tipo ma che con la Gizaga Architecture ci avrebbero salvato, non dico salvato, ma abilitato, agevolato in certi passaggi e questi clienti sono magari con dei problemi, perché ci chiamano e dicono "abbiamo questo problema, non riusciamo a evolvere il nostro software, non riusciamo a mantenerlo, non riusciamo a aggiornarlo" e quindi sbattiamo sempre in quel problema.Ecco perché mi è venuto proprio di parlarne spesso perché per me è un problema sentito, nonostante siano tanti anni che se ne parla, è un problema che in questo momento sto vedendo in tanti ambiti, non solamente in un linguaggio, ma in n linguaggi.Qui mi ha detto "cavoli, forse veramente non abbiamo quella consapevolezza, non riusciamo a capire i vantaggi o c'è qualcosa sotto che non ci permette di farlo".Tutte le volte diciamo che arriviamo sempre al solito punto, il solito trade off, ma quando si parte bisogna essere veloci, quindi installiamo il framework, installiamo tutte le librerie possibili e immaginabili che ci risolvano quel problema, arriviamo alla release che ci fa contenti e poi dopo succede che il business cambia, le cose cambiano, troviamo una libreria più interessante, troviamo una libreria, un tool che costa meno e il business cambia.Quindi il business quando cambia ti dice adesso dobbiamo cambiare magari da un'implementazione a un'altra e tu dici cavoli e adesso ho tutto il codice accoppiato e ci metto veramente tanto tempo, quindi la domanda poi che arriva è cosa facciamo, riscriviamo tutto o sistemiamo quello che c'è? E qui c'è il grande bivio, qui il grande bivio non è mai semplice da capire cosa conviene fare e cosa no, di solito non conviene riscrivere tutto, però bisogna applicare un po' di fix, applicare qualche approccio diverso e l'hexagonal architecture è uno di questi che ci aiuta.Vero, se l'avessimo fatto da inizio non avremmo avuto questi problemi, però possiamo farlo anche in corso d'opera, mi è capitato.Quindi è un tema che lo sento molto vicino perché l'ho visto veramente in software più e meno grandi che gestiscono tanti soldi e mi chiedo veramente come hanno fatto ad arrivare fino ad oggi, dopo dieci anni magari, come fa a stare veramente in piedi? Però dopo capisci che il team, il business capisce che i costi di manutenzione sono altissimi, senza un giusto approccio e quindi l'hexagonal architecture ci aiuta in questo.Ammetto che pensavo fossimo più consapevoli di alcune parti, invece abbiamo questo problema in tanti punti, diversi linguaggi, quasi tutti i linguaggi hanno questi problemi, ma anche tanti diversi da financial, dal tema IoT, tutti potrebbero avere questo problema e quindi è giusto esserne consapevoli e capire come poterlo, non dico risolvere, però almeno aiutarci a vivere meglio come dev anche andando incontro al business.Ed è proprio in questo momento, davanti a queste esigenze, che entra in gioco l'hexagonal architecture, quindi per aumentare la manutenibilità, migliorare la manutenibilità del nostro codice quindi aggiungere e rimuovere i feature più facilmente, per tenere il debito tecnico sotto controllo, perché insomma, prima o poi dovremo pur ripagarlo questo debito, e soprattutto per rendere la nostra codebase un pelino più predecibile.Ma a livello pratico si parla di hexagonal architecture, ma cosa devo fare per fare la mia architettura, per rendere la mia architettura esagonale? Bellissima domanda e qualcuno come sempre risponderebbe "dipende".A me piace dire che non ci sono linee guida, cioè il "by book" dici "devi far così, così e così", ci sono dei concetti, ci sono, c'è il concetto di porte e adapter.Cosa significa? Le porte sono fondamentalmente i nostri punti d'ingresso per il nostro dominio e gli adapter sono le vere implementazioni.A livello pratico cosa significa? Di solito io cosa faccio? Divido il dominio dall'infrastruttura principalmente.Quindi dico questa è la mia parte di dominio, la mia business logic ben protetta.Dentro questa parte non voglio parlare di framework, librerie, cioè deve essere agnostico, poi ci sono dei casi eccezionali, ci sono dei trade off, vero, però cerchiamo di essere un po' agnostici in questo.E lì dentro abbiamo le nostre porte, cioè diciamo bene, il nostro dominio per parlare fuori o chi vuole parlare con noi deve implementare questa interfaccia ad esempio, quindi se dobbiamo parlare col database c'è un'interfaccia che dice come salvarlo, come prendere i dati eccetera.Poi non c'è nessun riferimento, ci sono gli adapter nel layer di infrastruttura ad esempio, quindi mo che lo facciamo con Mongo, con Elastic, con MySQL, con Postgres, quelli sono cavoli del layer di infrastruttura.Perché questo? Perché ci deve abilitare a cambiare l'implementazione quando ne abbiamo necessità.E qui di solito mi viene sempre chiesto, in tantissimi team quando provo a spiegare, dicono ma non è la sovra-ingegnerizzazione, quante volte capiterà di cambiare le implementazioni? Capita, e quando capita se non ti sei un po' riguardato da questo c'è veramente da sudare freddo, perché dopo tu devi andare a toccare la logica di business, tutta intracciata magari con Corel Database come salvato, eccetera, e devi cambiare l'implementazione.A me è capitato di farlo a gennaio, cambiare totalmente un software di finanza da Elasticsearch a Mongo, quindi un cambio radicale dal puntista del motore e del database, senza toccare la parte di dominio.Abbiamo solamente toccato gli adapter, quindi come facciamo le query, ma tutta la parte di pagamenti, eccetera, non è stata toccata.E io ero molto tranquillo in cui tranquillo, praticamente ha la sua complicatezza, la sua complessità, però almeno non toccare la parte di pagamenti, la parte di come vengono fatti, che è la parte di logica di business, quello mi ha fatto prendere un bel respiro di sollievo, non vorrei mettere le mani in quella parte se devo cambiare le implementazioni.Idem, se cambiamo magari metodi di pagamento, abbiamo API esterne, anche quelle dobbiamo essere abili a rullate e a cambiarle quando ci pare, perché magari veramente abbiamo trovato un tool che costa di meno, che ha più feature.Ricordiamoci che stiamo facendo dei software che dovranno durare un mese, quelli sono proof of concept, quelli li prendiamo e li buttiamo in cestino, giusto, ma noi facciamo software che devono durare tanti anni ed è impensabile sapere che ora c'è un'API esterna e sarà così lungo, non è così facile.sarà così per i prossimi 10 anni, è veramente impossibile.Quindi proviamo a proteggerci, è vero, non è giusto porci problemi che non abbiamo, però sui servizi esterni cerchiamo di essere abbastanza ligi, e se voglio lo posso cambiare, posso cambiare l'implementazione, ma anche solamente aggiornare il nostro framework.Quante volte vi capita di lavorare, almeno ma secondo me, ho visto tantissimi team e progetti fermi a framework di 10 anni fa.Perché? Perché non riusciamo ad aggiornare, perché se aggiorniamo chissà cosa succede, perché è tutto interciato.Se invece ce l'abbiamo in una parte specifica in nostra layer di infrastruttura, perché il dominio non ha riferimenti al framework, possiamo aggiornarlo, dico quando vogliamo, però siamo più confidenti nel farlo.Questo secondo me è una parte di implementazione, ma il focalizzarsi poi sulle feature, una cosa che dico quando dobbiamo implementare l'exacto architecture è concentrati sulla feature, parti dal dominio, cerchiamo di risolvere il problema, non pensare all'implementazione, procrastiniamo con la decisione, quando partiamo con un nuovo progetto non pensiamo subito ci serve MySQL, ci serve questo framework, ci serve questa API esterna, eccetera.Queste decisioni per di possibili.Intanto, ragioniamo in temi di nostra logica di business.Cosa devo fare? Posso chiederti di spegnere la webcam? Anche Carmine perché vi sto ricevendo a tretti, scusatemi.No, chiarissimo, cioè concentrarsi su quello che veramente genera valore.su questo però spesso io vedo un'incomprensione, un misunderstanding spesso si pensa che tutta la parte di piattaforma non sia un elemento che generi valore ecco come si può trattare la parte di framework a livello di hexagonal architecture ci sono dei pattern per astrarre questo layer? Pattern ce ne sono abbastanza, mi risolto, mi affido abbastanza tranquillamente a CQRS e Event Sourcing perché te abilitano ancora di più questi disaccoppiamenti, quindi tu tu hai dei command bus, dei command handler e quindi in quel caso lì ti viene ancora più semplice riuscire a mettere il tuo framework, la tua parte del framework in un posto ben preciso, ben protetto dal resto.Quindi noi abbiamo il nostro framework nel nostro layer di infrastruttura e tutto il resto è disaccoppiato.Lo ragioniamo per interfacce e in questo modo modo siamo abbastanza abili e arruolati a fare tutto quello che vogliamo di aggiornamento, di cambi di implementazioni o altro.Questo secondo me ci aiuta veramente tanto a disaccoppiare e l'hexagon architecture con CQRS ed Event Sourcing diciamo che vanno abbastanza a braccetto.Mi sono trovato molto bene a farlo in questo caso.Concordo con Rimpio, io sono nei progetti più nuovi, noi siamo sempre andati ad architettura di questo tipo, diciamo più nella declinazione clean, la Uncle Bob, però alla fine sono veramente delle terminologie diverse, ma è davvero la stessa cosa.E ci siamo trovati bene, anzi anche diciamo in dei contesti magari un po' più, diciamo un po' più semplici, quindi magari tutta la parte di CQRS e Event Sourcing non c'era, ma rilegare magari il framework di turno o semplicemente la libreria che si occupa della parte HTTP e del routing a una parte infrastrutturale ben precisa che poi chiama, diciamo, vari user case comunque tutta la business logic del dominio è assolutamente impareggiabile.E diciamo, secondo me è qualche cosa che ne vedi anche tanto l'utilità quando fai tanta dependency injection, perché poi alla fine quelle persone che sono più framework addicted, insomma, danno comunque diverse cose per scontate.Quindi magari anche quando cominci a passarti le dipendenze in modo esplicito tra un layer ed un altro layer, secondo me, è qualcosa che apprezzi anche di più.Insomma, ovviamente questa cosa dipende anche tanto dal linguaggio in cui sei, nel senso io queste cose qui più che altro le faccio in Go ed in JS, quindi diciamo non ho mai avuto la vera possibilità di io ci contenere come magari ci può essere con un altro linguaggio, con un qualcos'altro framework.Quindi diciamo essere tra virgolette costretto ad esplicitare la mia dipendenza nel dominio, a fare l'implementazione rispettando quel il contratto, quell'interfaccia, secondo me è qualcosa che anche nella progettazione ti fa capire bene dove comincia la tua business logic e dove invece stai sostanzialmente facendo crude.La domanda però che mi viene in mente è una ed è molto semplice.Il fatto di disaccoppiare, so probabilmente dirò una blasfemia quindi correggetemi se sbaglio.Il fatto di disaccoppiare alle volte introduce complessità e costi.Esiste un break even che giustifica questi costi e secondo voi questo punto di rottura dove i i costi poi diventano benefici.Dove lo si posiziona nella vita di un prodotto che parte da proof of concept e arriva a prodotto commerciale? Bella domanda, bella domanda.Sicuramente è interessante sapere i limiti dei costi e quando arriviamo in break even.Ammetto che tutte le volte che ci ho pensato un po' con i team, quello che siamo arrivati alla conclusione è che i benefici li vedi sul lungo termine, non immediatamente perché all'inizio hai dei costi di complessità, perché ci sembrerà di essere più lenti, dobbiamo scrivere più codice, questo codice deve essere organizzato in una certa maniera, quindi c'è un po' quel costo, quel trade off, però a lungo andare quando il business viene a te e dice "bene, dobbiamo cambiare questa cosa", quando ci metti mezz'ora rispetto a tre giorni vuol dire tanto, è tutto lì dopo il guadagnato, quindi il break even arriva quando abbiamo il nostro prodotto, comunque dopo tot mesi e abbiamo fatto quell'attività di learning che ci permettono di dire "abbiamo sbagliato a mettere questa implementazione piuttosto usiamo un'altra oppure a dire al business ragioniamo sui dati ora diteci cosa possiamo cambiare quindi li mettiamo nel giusto comfort zone per dire quindi abbiamo dei dati possiamo cambiare come vogliamo le nostre implementazioni usare un altro tool eccetera perché dobbiamo sperimentare quindi abbiamo fatto quell'attività di learning e ora abbiamo tutto riguadagnato perché abbiamo la possibilità di cambiare le implementazioni come più ci pare.Secondo me è quello dopo che arriva il break even, proprio quando il business si sente anche vicino e coinvolto poi nel poter veramente dare il proprio contributo senza sentirsi dire che ci vogliono giorni e giorni per delle implementazioni.Non so se vi è capitato.Sì, sì, sono assolutamente d'accordo.A questo proposito diciamo una cosa che mi piace far vedere quando parlo di queste cose con alcuni colleghi.C'è un articolo sul blog di Martin Fowler dove sostanzialmente si discute del fatto se, diciamo, il software di una grande qualità, il suo costo è effettivamente giustificato.C'è questo grafico, magari poi lo linkhiamo tra le note del podcast, in cui sostanzialmente abbiamo che c'è, diciamo, inizialmente un periodo in cui le cose si fanno più lentamente e costano di più, ma perché è semplicemente quella curva di apprendimento, quello scalino che permette al team di prendere anche familiarità con certe metodologie, con certi tool, ma nel lungo andare questo costo si riduce drasticamente.Non solo perché magari hai utilizzato una tecnologia ed un'architettura invece di un'altra, ma perché con il software scritto in un certo modo anche il team ha più confidenza in quello che sta effettivamente facendo e può appunto dare delle certezze diverse al business e può anche implementare le nuove feature o cambiare i precedenti in un tempo che è infinitamente minore rispetto ad avere una code base diciamo inutilmente complessa.A me piace utilizzare il termine inutilmente complessa perché spesso un software ben progettato ha sicuramente della complessità, ma il vero game changer è quando riusciamo a rendere evidente quella complessità e semplice da comprendere per chiunque.In questo caso, l'architettura di questo tipo ti faccia veramente capire quello che la tua code base fa, ma senza soffermarti nello specifico dettaglio di quella query che magari su quel database deve essere fatto in quel modo strano, ma hai effettivamente la tua logica di dominio assolutamente pulita.Noi in azienda, da quando abbiamo adottato, diciamo, quando abbiamo sposato questo tipo di architettura, sui servizi nuovi stiamo andando veramente bene.Ecco, come approcciare ad una cosa legacy e ad una cosa confusa con questo tipo di architettura per tentare un refacto parziale? Non ho la minima idea da dove cominciare.Insomma, se tu magari hai qualche consiglio che puoi dare a me, magari anche ad altri che sono in questa stessa situazione.Diciamo, tutto quello che ho detto è più che altro su roba ex-novo, questa roba davvero legacy, l'ho trovato veramente complesso.Sì, avrei qualche caso da citarti, proviamo a raccontare una storia, una piccola storia.Mi è capitato un progetto che viveva ormai da 7-8 anni, che produceva veramente tanto denaro e valore per il cliente.E ero arrivato al punto in cui non credevano più nei loro dati, cosa vuol dire? Praticamente avevamo dei calcoli e secondo loro non erano incorretti, era un algoritmo particolare, prendendo dati ogni secondo da delle determinate cabine che speravano dei dati.Quando ho aperto il codice, mi ha fatto un assessment e tutto il codice era in 30.000 righe in un controller, 40.000 righe di un controller, tutte le query, tutto dentro, tutto funzionava a parte la parte principale sostanzialmente e loro erano abbastanza demotivati perché non riuscivano a capire il problema, un pochino già l'idea quando ho aperto la classe il controller mi ha chiesto pietà, ti prego aprila con notepad io non ce la faccio, però era tutto scritto lì e cosa abbiamo fatto? In pochi mesi abbiamo preso la parte core, la parte principale, quella che generava valore e abbiamo detto "bene, iniziamo a rifattorizzarla".Cosa vuol dire rifattorizzarla? Abbiamo preso magari quella action, quel metodo, l'abbiamo messo intanto in un servizio a parte.Abbiamo usato la Dependency Injection, poi abbiamo detto "sai che c'è? Iniziamo a spostarlo in una cartella a parte".Quindi tutto il codice che c'era prima l'abbiamo messo sotto una cartella legacy.Poi abbiamo creato una nuova cartella magari di codice, dove lì abbiamo iniziato a dividere la parte di dominio e di infrastruttura.E lì abbiamo messo il primo modello, quando abbiamo parlato di modello, abbiamo parlato di logica di business, abbiamo parlato a livello del cliente, quindi quello B2S language, parlavamo in una stessa lingua, e pian piano abbiamo creato delle interfacce che si interfacciavano con queste cabine tramite gli adapter.Quindi pian piano abbiamo iniziato a migrare alcuni pezzi nella nuova parte, nell'architettura esagonale.L'abbiamo fatto solamente per le parti core, perché non aveva senso farlo per tutto, era dieci anni di sviluppo, ma per quella parte che aveva dei problemi l'abbiamo un po' rifattorizzato, poi abbiamo iniziato a portarla fuori sotto test, logicamente, perché non c'erano neanche i test, logicamente, e a creare le nostre interfacce che parlavano con i servizi esterni, con queste cabine che che erano in giro, sparse per il mondo.Questo è un approccio, secondo me funziona abbastanza perché è inutile mettersi su quel codice legacy e provare a organizzarlo lì, quello ormai è legacy, quello ormai è strutturato in una certa maniera che creiamo solamente più confusione, piuttosto creiamo una parte a sè stante con quell'architettura e pian piano migriamo.Anche lì ci avevamo chiesto, ma è meglio riscrivere tutto o no? Non aveva senso iscrivere tutto.Di solito si affiancano questi pezzi di codice in cartelle a parte o addirittura con un altro software a parte.Anche qui è capitato un altro caso, un team fermo a una versione vecchissima di un framework, non riuscivano più ad andare avanti perché era proprio bloccato tutto.Parli di Symfony 1.4 secondo me.Parlo di Zend 1 in questo caso però siamo lì.Il team è demotivato perché considerate anche questo, cioè lavorare su framework, liberie vecchie, cioè pian piano uno non trovi le persone che abbiamo voglia di lavorarci, due le persone che ci sono dentro non è che sono così motivate poi perché vedono sempre le stesse cose, non vedono cose nuove, pian piano quella motivazione scende.Cosa abbiamo fatto in quel caso? Abbiamo creato un nuovo repository e lì abbiamo iniziato con un nuovo framework, comunque con un'architettura nuova, e pian piano tutte le API, piuttosto che chiamare il vecchio software legacy, chiamavano quello nuovo, lo abbiamo affiancato, e pian piano abbiamo migrato le varie parti.È vero, quello legacy non è mai morto, però erano quelle parti che in una fine non erano più core.È importante migrare le parti core, quelle magari che hanno dei problemi nella parte nuova, perché ce l'abbiamo organizzata meglio, ce l'abbiamo più, diciamo, sotto controllo, sotto test, e sicuramente ci agevo poi nel corso degli anni a devolverla.Questi sono due approcci che mi è capitato di utilizzare e non so se vi tornano, magari ce ne sono altre anche migliori, però questi sono casi d'uso vincenti che ci hanno fatto uscire da quella big ball of mud in cui ci eravamo trovati e abbiamo aiutato i clienti a uscire da questi problemi anche aiutando il team che logicamente non riusciva più a evolvere, più a capire da che parte farsi per riuscire a sistemare i problemi e a rispettare le richieste del business perché comunque continuavano ad arrivare.Sì io ne approfitto per fare un lancio promozionale nel senso che scherzo qualche tempo fa ho registrato un episodio sul refactoring dove abbiamo trattato molti di questi argomenti si chiama forse calvino e refactoring ma vi vi metto comunque il link nelle note dell'episodio e là andiamo proprio a parlare della riscrittura, quando ha senso e cosa ha senso riscrivere.C'è da dire che quello che mi chiedo io è quando noi...premesso che oggi visto che siamo un po' tutti amanti dell'architettura esagonale mi toccherà fare l'avvocato del diavolo.Quindi non odiatemi ma sono quello che deve fare le domande un po' rompiscatole.E per questo io risveglio il Franz che è in me.Tra l'altro ne approfitto per salutarlo.Ciao Franz.Quando noi utilizziamo l'idea, l'approccio di fare degli adapter per tutto quello che è il layer sottostante, quindi la piattaforma, non rischiamo di allontanarci troppo da, nel modo più generico, dove gira il nostro codice, che ne so, la nostra data source e quindi non rischiamo un degradamento significativo delle performance.se sì, secondo voi cosa dobbiamo fare per evitarlo? Sicuramente non so quanto ti puoi allontanare dal tuo codice, diciamo, e le performance potrebbero anche addirittura migliorare in alcuni casi, proprio perché hai più sotto controllo, hai questo disaccoppiamento che ti permette anche di avere dei test che ti misurano le performance a sé stanti e capire se ad esempio tu hai un algoritmo nel tuo dominio devi capire se è quello che va lento o magari è la tua implementazione che va lenta, magari la connessione al database è lenta, magari c'è un problema con un driver, non so, però riusciamo a essere molto più diciamo selettivi in quello che vogliamo misurare, selettivi in quello che vogliamo testare e anche qui riusciamo anche a capire meglio i bug, perché riusciamo anche magari a dividere i vari mondi nei vari log che dopo vengono magari concentrati in un unico solo, però riusciamo a capire dove è stato il problema, è stata una parte di scrittura, una parte di lettura, quindi secondo me ti porti dietro dei vantaggi che le parti performance quasi non ne risentono, perché alla fine non è che sei così lontano, alla fine tu stai rispettando delle interfacce nei tuoi adapter e sei molto tranquillo di quello che fai perché tu stai rispettando un'interfaccia di dominio.Penso che di performance, poi o poi parlando anche di data source eccetera, non mi è mai capitato di vedere problematiche di questo tipo.Non so se avevi casi d'uso specifici.Ma diciamo, sono, in realtà sono d'accordo, cioè, secondo me il fatto di dividere le cose ti dà sicuramente delle astrazioni, ma ti dà delle astrazioni utili.Se io posso isolare quella che è la mia business logic da un dettaglio, perché poi alla fine il gioco dell'hexagonal è che puoi permetterti di prendere delle decisioni dopo, perché magari ti concentri sulla tua business logic e puoi permetterti di decidere in un secondo momento dove salvarla.Secondo me già il fatto che se mentre pensi al dominio ti stai ponendo il problema delle performance del tuo database che stai usando, non lo so, un nuovo SQL come un database relazionale per qualche motivo e quindi c'è questo problema di performance, eccetera, eccetera, probabilmente stai un po' affrettando i tempi e non ti stai veramente concentrando sul tuo dominio, insomma.Quindi, boh, secondo me sono delle astrazioni utili e come dicevi anche tu, ti permettono anche di poter misurare in maniera precisa tutti i vari aspetti della tua applicazione.Secondo me, ovviamente stiamo comunque parlando di qualcosa che ha, almeno secondo me, senso in determinati contesti.È ovvio che se ho il crude della chiesa, insomma, che io faccio l'interfaccia che fa save e la mia parte di dominio è l'eccezione, Ovviamente lì si sta over-ingenializzando tutto e quindi magari la logic vera è qualcosa con cui attendereci, vai a convivere bene.È vero anche che spesso, almeno io parlo dal mio punto di vista personale, alcune cose sono cominciate crude ed è venuto il dragone dentro allo sprint dopo.Quindi effettivamente alcune volte abbiamo accettato lo Scott di over-ingenializzare all'inizio e di seguire questo tipo di architettura, anche se nel momento X non ne vediamo veramente i benefici, ma allo sprint x più uno, quando non era più crudo, ma c'era effettivamente del valore da inserire all'interno del domino della applicazione, ci siamo già ritrovati con le fondamenta mise.Secondo me è difficile, almeno secondo me questa è un'altra domanda, è difficile far comprendere la reale necessità di un'architettura simile anche su software complessi, finché veramente non ci si sbatte la testa.Perché magari ti incontri comunque delle persone che sono framework addicted e non è che ci sia niente di male a preferire un framework, preferire una cosa rispetto un'altra.Però magari dopo, cioè nel senso, hai il tuo applicativo monolitico MVC e o fai FatModel o fai FatController, arrivi comunque ad un certo punto dove disaccoppiare e cominciare diciamo ad isolare le cose, qualcosa che devi necessariamente fare.Nel senso, diciamo, World Opinion, se puoi veramente permetterti di fare MWC, se puoi fare crude puro, significa che stai facendo crude puro, quindi probabilmente non senti nemmeno la necessità di questa roba qui.Però magari se hai un applicativo complesso e hai anche tu il tuo controlle da 15.000 righe e non riesci a vedere il vantaggio di avere un approccio del genere, credo che ci sia proprio qualcosa di sbagliato a monte nel modo in cui una persona approccia il proprio software.Se c'è della complessità oggettiva e faccio finta di non vederla, può essere MWC, hexagonal, clean architecture, quello che vogliamo, ma c'è un problema di base, insomma.E allora a questo punto vi state chiedendo, ma la domanda qual è? Come faccio a convincere un team che ragiona in questa maniera qui, diciamo, ad evidenziare i vantaggi di un'architettura del genere, però senza sfociare in quella curva cognitiva quasi grande che poi dicono "ok, allora basta".Come faccio ad approcciare il genere? Questo è un tema caldo, è un tema caldo che spesso salta fuori.A me è capitato di approcciare in diversi modi, sicuramente il fatto di vedere i benefici, far capire cosa si va incontro e avere una idea di good enough, è quel concetto in cui non dobbiamo mettere i fiocchi perfettamente a tutto, dobbiamo arrivare a un punto in cui bene poi lo perfezioniamo piano piano, perché stiamo facendo del learning, quindi dobbiamo capire anche a livello di business quali sono i vincoli che abbiamo, quali sono le leve che ci aiutano, se è il denaro, se è il tempo, se è la qualità, proprio con questo cliente in questo caso.Noi spesso in flowing ragioniamo con dei contratti SOR, contratti settimane, soddisfatti, rimborsati e aiutiamo a avere questi… facciamo dei contratti soddisfatti o rimborsati di una settimana di solito, sono interazioni in cui promettiamo al cliente delle storie e qui come facciamo a implementarle? Col team tuttavolta diciamo quale tool usiamo, non pensiamo al tool, pensiamo al dominio, al comportamento, quindi andiamo con un event storming, capire i vari comportamenti e poi decidiamo i tool.Per fare questo dobbiamo essere un pochino ligi a seguire un pattern e quindi cerco di far capire ai team che aver l'hexagonal architecture come pattern nelle parti soprattutto core ci aiuta a fare questa, procrastinare quelle decisioni implementative finché non sappiamo esattamente cosa ci serve.È inutile che lo decidiamo a inizio.Oltretutto anche delle retrospettive.Mi piace anche fare retrospettive iniziali, cioè cosa ci aspettiamo da questo progetto? Spesso le risposte sono voglio imparare qualcosa di nuovo eccetera.Bene, l'hexagon architecture ci aiuta a imparare cose nuove, a modellare il dominio, a imparare questo pattern e pian piano far capire ai team che tanto tra due o tre anni saremo ancora qui, è inutile che noi usiamo i soliti pattern, i soliti workflow, cerchiamo di fare qualcosa che ci aiuti nel lungo periodo, perché non è che stiamo facendo uno sprint di 100 metri, è una maratona quello che dobbiamo fare, cerchiamo di agevolarci il lavoro tra n mesi e quindi tutti questi vantaggi spesso portano il team a dire siamo confidenti, però deve essere una decisione corale, deve essere qualcosa che ci piace a tutti, ci torna, soprattutto per il contesto in cui siamo.È inutile forzare la mano, perché come sempre non è che una soluzione che funziona per un team, per un progetto funziona per un altro, quindi anche qui dipende, io cerco di consigliarla sempre, mi è capitato anche ai team che mi dicono guarda, questo software è talmente semplice che può anche non avere bisogno.Poi dopo 8 mesi succede che venga fuori anche il dragone, ma quelli sono dettagli.Però diciamo che provo così a spiegare i vantaggi perché io ammetto che ne vedo tanti, però deve essere una decisione corale, di team, condivisa, perché sennò non funziona.Ma secondo voi si può fare un crude leggero, quindi senza troppo effort, su un'architettura esagonale? Perché è una cosa che mi sto chiedendo da un po'.E se sì, che trick adottereste? In realtà nessun trick, alla fine avremo le nostre entità e tutta la logica del nostro dominio che non è nient'altro che fare crude, quindi una parte salva, una parte prende, una parte filtra insomma e l'implementazione con tutti quanti gli altri layer.Secondo è assolutamente fattibile.Ammetto comunque anche di farlo diverse volte, perché magari anche nell'applicazione semplice ti può venire comodo.Ad esempio, in tantissimi pet project che ho, se non l'avessi fatto così, anche se sono crude semplici, il mio interact, il mio ggjuicecase, fa xyz.save, insomma, avere comunque la possibilità di poter rimandare alcune decisioni mi ha fatto perdere almeno tempo quando magari ero convinto di andare su Postgres e poi sono andato, non so, su MySQL o su un'altra cosa, insomma.Quindi, secondo me, c'è assolutamente il vantaggio.E secondo me dipende anche da come vuoi strutturare anche la tua parte infrastrutturale.Se sono su Node, se sono su Go, insomma, so che la mia parte infrastrutturale per la parte di Gateway HTTP sarà Boo, con una routing library, e poco più, probabilmente, se lo dovessi fare in Ruby, mi è capitato di farlo comunque in Ruby, avere nel layer infrastrutturale HTTP tutto Rails, considerando che comunque alla fine anche il layer di persistenza lo farei comunque con l'Orma, e via via portarsi dietro già il framework che è bello grosso, più tutta questa, diciamo, più tutta questa code base in più, diciamo, in un contesto del genere forse opterei per non farlo, ma se posso stare quanto più diciamo snello possibile, secondo me non c'è nessun problema.Mi accodo, ho fatto anch'io alcune prove con dei kata, per esempio, non lo nego, ho 20 volte, tipo il gioco del Triss, in diversi modi, anche con l'architettura esagonale, proprio per spingere, per sforzare, per stressare questo concetto e ammetto che se devi fare un crude è una sovraingenializzazione, sì, però ammetto che vedo veramente pochi progetti crude, quindi un po' di logica c'è sempre, quindi quel mimo alla fine ormai è il mio mio mindset all'aggiornare con questo pattern e quindi mi viene spontaneo quasi farlo.Diciamo che in un crude lo vedi proprio che scrivi tanto tanto codice e con un altro pattern, con un altro sistema lo avresti fatto in molto meno, però anche qui dipende sempre qual è lo scopo, se lo scopo è un proof of concept, un test va bene, se dobbiamo farlo per un software che deve durare n anni, che a un certo punto potrebbe evolvere, ma potrebbe anche convenire.Anche qui dipende anche dal team cosa si sente confidente di fare.Sono scelte che devono essere prese consapevolmente, sapendo i pro e i contro, perché ci sono pro e contro.Tanti pro, ma alcuni contro sicuramente ci sono, se no tutti useremmo forse l'architettura esagonale.Secondo me una cosa simpatica in questo tipo di architettura e di struttura del codice è avere della code generation che funziona.Faccio un esempio banale.Noi abbiamo alcune delle parti che sono code generation in Go, dovrà, ci saranno tutti i vari Google Istiche dovrebbero mettermi alla forca, però, è una cosa che ci ha dato un boost impressionante.Poter fare scaffolding di diversi layer o anche di tutto il progetto con un sistema di code generation che funziona ti aiuta anche ad essere veloce e magari lo scotto di scrivere tanto lo codice per un crude non lo vedi nemmeno, perché hai fatto lo sforzo prima di cercare di automatizzare quelle parti diciamo più noiose.Ad esempio in Go, se vogliamo convertire, ma mi sento in Go, ma sarà stessa cosa anche in Java, diciamo in un linguaggio tripizzato, riuscire a convertire magari delle entità tra un layer e un altro, quindi fare banalmente mapping, delle cose senza passare per reflection o cose simili che magari non puoi nemmeno farlo, quella è una parte noiosa.Avere un sistema con cui puoi automatizzare quel lavoro scimmiesco, se così si può chiamare, secondo me ti fa anche apprezzare tanto di più questa cosa anche nei progetti più piccoli.Ora, nel senso, almeno nella mia esperienza è stato così.Sì, vero.E tra l'altro solitamente quando si guardano i quick start dei framework raramente si vede un'architettura così organizzata, no? Correggetemi se ho appena detto una fesseria.Io ho tutti i quick start partendo da quello di Symfony.Adesso in realtà io sono un po' indietro qualche versione, io ricordo che erano dei fat controller con super, super, modelli super snelli pronti per la prova a costume.E qua su questo so che Carmine ha un dubbio no? Allora, diciamo, il mio desiderio è riuscire a vedere anche dei framework che ti possano, diciamo, buttare fuori un tipo di scaffolding di questo tipo.Ma a questo punto, giusto così anche io per fare l'avvocato del diavolo, ma se domani mattina Symfony o domani mattina Rails o domani mattina qualunque cosa, invece di fare il classico scaffold MWC più facilmente comprensibile, a cui comunque la maggior parte sono diciamo abituati, ti sputa fuori una cosa del genere.Quanto cala la popolarità di quel progetto tra chi lo usa, visto che la curva di apprendimento è sicuramente più ripida? Bella domanda, ci sta tutta.Parlo per Symfony, perché è un framework che si è evoluto veramente tanto in questi anni, tanto è vero che ora quando uno lo installa tramite composer non c'è veramente nulla, perché è tutto separato in vari pacchettini.Secondo me, a parte che ci sono dei progetti che sono già fatti come la tua desiderata, Carmine, symfony, hexagonal architecture, tu lo installi e c'è già tutto lì, ma poi alla fine cosa succede? Cambi le cose, perché ogni progetto è a sé stante, non c'è come ti dicevo una linea guida, quindi ad esempio tu installi e piuttosto che avere src e controller hai src infrastructure, application, domain e i controller dentro infrastructure, perché dipende, dipende dopo come lo vuoi approcciare, ad esempio in un nuovo progetto che sto facendo, con un team, noi abbiamo deciso di mettere i controller in un'altra parte che non sia l'infrastruttura chiamata UI, che è praticamente la nostra parte di applicativo che parla con l'esterno, diviso nei vari contesti, contesti che sono anche le nostre porte, tipo REST API, CLI command, eccetera eccetera.Quindi dopo, anche qui è un dipende dal tipo di progetto, ecco perché secondo me non viene fatto, perché dopo ci sono diverse implementazioni tutte le volte dovresti essere lì a ritoccare le varie cose.Cosa ho fatto io negli anni? Mi sono fatto dei tool, chiamiamoli così, dei piccoli make file, qualcosa che mi abiti questa automatizzazione, quindi quando scarico esempio Symfony, io lancio un comando che mi sistema magari i path dei controller, mi installa già alcune librerie, eccetera, perché alla fine preferisco farlo in questo modo, poi tanto alla fine succede che lo vado a ritoccare, perché magari con un team approviamo un nuovo approccio.Mi è capitato di vedere addirittura i controller dentro application e quando ho visto il team ho detto "perché mettete i controller dentro application?".Mi hanno dato una motivazione valida, tale per cui per quel progetto aveva senso.Quindi non essendoci regole, non essendoci rule proprio specifiche di come implementare, di come organizzare il nostro codice, i tool, i framework dicono questa è la base, poi dopo ci fai tu quello che vuoi, perché ricordiamoci che i framework sono un tool che noi dobbiamo utilizzare, non dobbiamo farci guidare dal framework, ecco perché mi piace che siano più così, perché dobbiamo essere noi a dire come implementiamo le cose, non farci guidare dal framework, perché poi dopo cadiamo nell'altra parte che se il framework dice così allora è tutto valido, no, perché dipende proprio dal progetto, dal team, dipende da che tipo di approccio vogliamo eseguire e cosa ci piace esplorare.Noi stiamo esplorando con questi esperimenti, con questo progetto, ci stiamo trovando bene? Sì, molto probabilmente faremo un articolo, daremo dei feedback su quello che abbiamo fatto e lo condivideremo perché è giusto condividere all'esterno per anche farci dire guarda non ha senso quello che avete fatto, capisco il motivo.Ecco perché secondo me i framework non partono già con un'idea di questa separazione, perché sarebbe troppo soggettivo a un certo punto non essendoci quella linea guida e soprattutto ti perderesti quella parte di dev che non hanno ancora ben chiara questa parte, l'example architecture o comunque quei pattern a livello enterprise, brutto a dire però che ti aiutano a mantenere meglio il codice, quindi ti perderesti quella parte di Dev che sta imparando, che sta iniziando con i primi framework, Symphony, Larvel, Spring, Tor, quello che uno vuole provare, perché aggiungeresti la complessità in più.Ricordiamoci, i framework sono dei tool, non dobbiamo farci guidare dal framework.No, no, sono d'accordo, diciamo, la mia domanda era più una provocazione, perché nel senso nel mondo Ruby c'è Anami, che ha tutti gli effetti un framework, insomma, che però diciamo nella sua filosofia cerca di seguire il modello della clean architecture e ti propone anche uno scaffolding del genere.Io ho provato ad utilizzarlo, ma come hai detto anche tu, sono finito comunque per ritoccarlo un po' anche per abitudine, un po' anche perché effettivamente non mi piaceva.La mia era più una provocazione che ha, perché spesso una delle cose che mi sono state dette è "ma se non lo fa Symphony, se non lo fa non lo fa Spring, allora si fa che non si fa e invece nel senso no, nel senso sì.E come fareste approcciare uno junior a questa cosa? Questa è pure un'altra cosa che mi sono sempre chiesto, perché? Perché magari c'è chi in questo mondo c'entra comunque grazie a un framework, comunque grazie diciamo a un set di conoscenze che non arrivano diciamo a questo scalino di complessità o di consapevolezza.Di solito con Dev Junior, come ci si approccia in questi casi, io faccio molto pair e tanta code review, quindi a un certo punto prendo magari questa persona, questo Dev che ha voglia di imparare e dico bene, adesso lavoriamo un po' insieme, facciamo un po' di pair insieme spiegando gli antaggi e tutti i vari step.Di solito non mi piace dire studia un framework, perché secondo me è un po' sbagliato, piuttosto dico studia dei pattern, design pattern, come fare test, come andare anche sul TDD, a meno di sapere cos'è, poi ci arriviamo con l'hexagonal architecture anche a fare TDD perché non aggiungiamo troppe complessità all'inizio.E pian piano provare a fare quel lavoro di accompagnare il dev a assimilare questi pattern, a questo pattern, dandogli proprio anche la possibilità di sbagliare, avere in team le persone che possono sbagliare ti veicola a far questo, quindi senza avere quella paura "Oddio, aspetta, se sbaglio vengo fustigato", no, è giusto spiegarle cose, farle provare e dopo fare il review, lavorarci insieme e spiegarle le varie motivazioni per cui una cosa è giusta e una cosa è sbagliata.Secondo me non è che un junior non possa imparare l'hexagonal architecture, si tratta sempre di come viene approcciato e come viene accompagnato, è inutile buttarlo nella fossa dei leoni dell'hexagonal architecture da solo, bisogna accompagnarlo e spiegare pian piano il perché.Quando uno spiega il perché pian piano le cose si sistemano e avere le persone nel team che ti aiutano e che ti dicono "puoi sbagliarci, non ti preoccupare se sbagli, intanto provaci" e poi ci andiamo dietro.È uno scalino importante? Sì, è uno scalino importante, però sicuramente è uno scalino molto molto importante secondo me per la vita di un dev.Ammetto che l'avrei voluto fare prima negli anni, ma logicamente dipende sempre dove finisci, in quali progetti, in quale team finisci, in quale azienda, quindi è sempre un dipende, però penso sia fattibile, ammetto.Hai detto una cosa molto interessante riguardo ai Junior cioè il fatto che qua adesso dico la mia opinione che un po' secondo me coincide con quello che hai appena detto, cioè il fatto che se tu metti un Junior in una codebase, il Junior è anche un po' sveglio, dopo un po' il pattern di sviluppo lo riconosce, non parlo di pattern di programmazione, proprio la struttura con il quale si deve muovere all'interno di quella codebase prima o poi a forza di vederla la assimila la differenza sta proprio nello stimolare la consapevolezza di quello che sta succedendo quindi capire che si tratta di hexagonal architecture capire che i vantaggi di questo tipo d'approccio sono questi e questo lo può fare solo un mid o un senior che si siedono a fianco e gli dicono "guarda se non facciamo così questo è il sangue" tra virgolette.Io invece ho un'altra curiosità.Prima ho fatto la mia introduzione wikipediana, copiata paro paro da wikipedia dove il messaggio che volevo passare è che poi, come tante cose che ritornano di moda, alla fine non sono poi così nuove.Nel senso che l'hexagonal architecture emerge già dal '92 con Ivar Jacobson, stiamo parlando di 20 anni fa ho contato bene? No, 30 anni fa di più? esatto eh, 30 anni fa e e allora non si parlava tantissimo di domain driven design, anzi credo che non se ne parlassi affatto non vorrei dire una fesseria e la mia domanda è siccome è tornata di moda è secondo me uno dei driver che ha reso un po' più shining questo tipo di architetture e proprio l'abbracciare il mondo del domain driven design e del CQRS.Si può fare hexagonal architecture senza DDD? Questa è una domanda che non mi è mai capitata, però all'ora che ci penso può avere diversi...Ho perso mezza serata ieri ragionando su questa cosa, provando a dare una risposta a questa cosa.Si può fare, nel mondo del software si può fare tutto, però alla fine ci sbatti a un certo punto perché in exact architecture quando tu ad esempio dividi già le porte ad adapter, quando tu già metti la tua business logic da una parte, già inizi a fare qualcosina.la tua business logic a un certo punto, avendola separata, parla il linguaggio di dominio, quindi siamo finiti nell'ubiquitous language.Diciamo che è molto facile prendere i concetti di DDD, perché DDD è veramente vasto, quando uno dice voglio imparare domain driven design, ci sono tante cose da imparare, la prima secondo me, la più importante è l'ubiquitous language, quando sei nel tuo dominio, che esponi i tuoi comportamenti e le tue interfacce, molto probabilmente stai toccando l'ubiquitous language, quindi ci siamo, siamo lì dentro, è molto facile ricaderci, ecco perché spesso vanno a bracetto tutti questi concetti in maniera graduale, non bisogna farlo per tutto il software, non bisogna esempio CQRS e Vensourcing, non è possiamo farlo per tutto il software, possiamo farlo per una piccola parte, però secondo me alla fine ci cadi sempre in qualche concetto di domain driven design.Penso di non aver mai visto progetti con l'hexagonal architecture senza dei concetti di domain driven design secondo me.Esatto, questa era la considerazione alla quale ero arrivato ieri sera, però non mi sono dato per vinto, quindi vi voglio condividere cosa ho trovato.Ripeto, l'ho trovata ieri sera non ho avuto modo di approfondire anzi qui lancio un appello agli amici che conoscono questo approccio se vogliono fare dei follow up le porte del bar sono sempre aperte però ho trovato questo pattern che si chiama functional core imperative shell siamo nel dominio della programmazione funzionale e qua ritorna appunto il concetto della funzione pura e della shell imperativa La scena imperativa è il nostro concetto degli adattatori, cioè tutto quello che sono adapter che ci connettono con la parte di piattaforma in genere e con l'utente e tutto ciò che è la logica di coordinamento, quindi in realtà tradotto con la zappa ci dovrebbero stare anche che ne so le nostre rotte in questa in questa in questa parte e poi c'è la funzione pura invece che il functional core che delega Appunto tutto il resto Alla parte di imperative shell per cui la funzione pura riceverà in ingresso il risultato degli adapter e sputterà qualcosa che sarà adattato.Un po' ritorna come concetto, riconoscete delle similitudini anche voi? Mi sembra che come concetti ci siamo molto vicini, ma come sempre lo chiamo in diversi modi ma bene o male finiamo in quel processo, in quel flusso.Io ci vedo delle analogie.non so fino a che punto a livello implementativo, però i concetti sono molto simili su alcuni aspetti, niente da dire.Sì, io credo che poi alla fine si ritorni sempre lì, insomma alla fine diciamo sono cose che alla fine il fatto stesso che non vi sia una guida unica all'implementazione in pratica ci può veramente lasciare con tutti i pro e con tutti i contro, diciamo, all'implementazione di questi stessi concetti in tanti modi diversi, insomma.Quindi, ovviamente questa cosa qui per me magari è un bene, magari per delle persone che sono abituate comunque a ragionare o a sviluppare su dei binari un po' più precisi, un po' più definiti, questa cosa qui può spaventare, alla fine anche che questa è è stata una delle obiezioni che mi sono state fatte.Se sono concetti ed è comunque, diciamo, sta a me implementare la soluzione con tutti i trade off del caso, nel senso, sto usando quel linguaggio per la mia parte infrastrutturale, ho scelto quella cosa XYZ.Ovviamente ci sono sempre trade off e secondo me questa cosa qui è una cosa che spaventa tanti, il fatto che non ci sia proprio la guida e il libro preciso che dice "allora, se è in PHP, se è in Java, se è in Ruby, fai così".Secondo me è un fatto positivo, non so come pensate, però nel senso è una cosa che è molto molto personale.Ahimè, vi devo interrompere perché è arrivato il momento di ringraziare chi questa settimana ci ha offerto da bere.Infatti Gitbar si sostiene grazie alle vostre donazioni.Quindi questa settimana abbiamo tre persone che ci hanno offerto tante birre.Il primo è Luca Gallinari che ci ha offerto quattro birre scrivendo veramente un bel podcast, clima simpatico, ritmi leggeri e contenuti variegati.Continuate così.Naturalmente Luca non è l'unico.Insieme a lui abbiamo anche Matteo che ci ha invitato tre birre.Matteo Mirk scrivendo davvero un bellissimo podcast pieno di contenuti e di persone interessanti.Sono felice di averlo trovato.E per finire c'è Luca che ci ha invitato cinque birre scrivendo questo giro ve lo offre la casa.Grazie a tutti, grazie a voi.Gitbar non è un podcast da gola secca.Questa puntata devo dire che ha in qualche modo celebrato il nostro amore verso l'esagonal architecture.Quindi per parcondicio la prossima la faremo con DHH e Taylor O'Toole giusto per riequilibrare.Scherzo.Io ho un'altra domanda.Bandole ex ex gitma adesso.Io ho un'altra domanda Alessandro.Se davanti a te c'è un junior che vuole iniziare ad approcciare a questo mondo e ha un P.O.C.da fare e vuole provare, cosa gli consigli di fare? Prima cosa, provare a ragionare proprio in termini di focus on the feature, cioè focalizzati sul problema, cioè risolvi il problema nella tua parte protetta e di dominio.Prova a mettere giù un test, possiamo mettere giù insieme un test prima per validare la feature e dopodiché proviamo a implementarla, con o senza framework, con o senza librerie.Proviamo a farlo con il minor dispendio di tool esterni, cercando di focalizzarci proprio sul problema, perché spesso quello che vedo è che ci focalizziamo su come arrivare alla soluzione facendoci aiutare da tutto quello che c'è esternamente.Poi a un certo punto ci accorgiamo che abbiamo accoppiato tutto e quello è sbagliato, quello è farci guidare dal frame o dalla libreria invece proviamo a vedere il nostro problema veramente qual è il nostro problema è questo, poi ad un certo punto è vero dovremmo salvare qualcosa, ad esempio prendere i dati bene, mettiamoci in interfaccia, quindi prima cosa focalizziamoci sul problema proviamo a risolverlo quello che deve venire esternamente iniziamo a mettere dell'interfaccia poi non è scritto sulla pietra In Exagon Architecture ti aiuta anche a fare refactoring più in fretta, o comunque ti abilita a farlo.Io ho visto veramente poche volte scrivere del codice in Exagon Architecture e poi non essere mai modificato.C'era appunto stamattina mi è arrivata una pull request dove un dev del team in cui sta lavorando cambia tutte le cartelle in cui ci sono alcune parti.Perché? Perché aveva più senso spostare in un'altra.costo dell'operazione veramente poco, valore tanto perché era nel punto giusto e aveva una valida motivazione.Quindi anche qui rendere quella consapevolezza a un junior di dire tanto mettilo qui perché in questo momento è il good enough, cioè il posto migliore, il buon abbastanza per dire ci va bene qui.Poi quando le cose evolvono iniziamo a ragionare ogni volta su cosa veramente andiamo a toccare, se deve essere spostato o meno e così iniziamo espandere partendo dal dominio e iniziamo a andare fuori.Questo secondo me è come dovrebbe partire ogni feature, cioè partire dal problema e pian piano espandersi fino ad arrivare alle parti esterne, alle parti degli adapter, di come veramente andiamo a implementare se ci serve qualcosa dall'esterno o qualcuno ci deve chiamare dall'esterno.Sì, vero, mentre parlavi mi è venuta in mente un'altra cosettina che volevo condividere con voi.Fare "Hexagonal Architecture" vuole anche dire scrivere il nostro codice con la "Destroyability in Mind", con in mente già l'idea di doverlo distruggere, cioè che il nostro codice non è eterno, che quel tassello è talmente indipendente che se muore non piangono tutti, può essere facilmente sostituibile.Quindi è un po' il single bus, rimuove il single bus factor dal nostro codice, no? Eh sì, perché però può anche innamorarsi del codice, del proprio codice un attimo, e poi anche lì è un pattern che riconosco in tanti progetti dove "questo è il codice che ho scritto, non lo voglio modificare" eccetera.Il nostro codice deve essere fatto presso anche un modificato, si evolve, le cose cambiano, è inutile innamorarsi di un pezzo di codice, se a un certo punto non serve è inutile tenerlo lì, togliamolo, cancelliamo quelle cose che non servono, è molto importante secondo me.Posso dire una cosa che non so, è un po' così, nonostante io sia appassionato del codice scritto in un certo modo, a me piace scrivere codice, in un buon software probabilmente il codice è la parte che ha veramente meno valore, è l'idea, è l'architettura di tutto che ha veramente valore, almeno secondo me.Il coincogene si può sempre buttare, si può riscrivere, si può cancellare.Nel senso, almeno questo è quello che penso io.Sei scritto con raziocino, hai ragione da vendere.Io direi che, vista l'ora, con questa Per la perla di filosofia di Carmine, noi ci accingiamo a chiudere le puntate.Io non so come fa Carmine ogni tanto a fine puntata a servirci queste perle.Carmine, qual è la tua fonte misteriosa? Svelacela.La mia fonte misteriosa, le puntate del Potea sono nessuna registrazione video.o diciamo anche senza webcam, ma credo sia l'oscillazione sulla sedia ad ondolo.Non so, c'è l'ispirazione, i pensieri che vanno così e ad un certo punto si firma.Che bello.Potete comprare la sedia ad ondolo di Carmine.Questo è il Gitbar che ci piace.No, Alessandro, tu pensavi che finisse qua, ma come ben sai è arrivato il momento tipico e topico dei nostri episodi.Il momento si chiama "Il Paese dei Balocchi" ed è il momento in cui i nostri ospiti condividono con noi un libro, un talk, un'applicazione, un qualunque cosa possa aver catturato l'attenzione o essere stato utile nella carriera."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Qui ammetto che potrei cadere nel banale, però il Clean Code e Clean Architecture, secondo me, sono due libri che hanno veramente cambiato tante parti e cadono veramente nel banale, però sono quelle cose che ti porti dentro e che spesso io ce l'ho sul comodino, che leggo come tipo Bibbia, su tutto il clean code.C'è un altro libro che è Get Your Hands Dirty on Clean Architecture, che è un libro che mi sono abbastanza letto, che comunque mi ha portato del valore, della conoscenza, dopodiché si sfocia sulle parti di domain in design, però questi secondo me sono quelli che mi hanno fatto svoltare su alcuni concetti, se per quanto siano semplici, per quanto ogni tanto io mi risfoglio ancora, per me sono sacrosanti.Progetti interessanti sull'hexagon architecture, sicuramente faccio un po' fatica a averne trovati, secondo me la cosa più interessante da fare o comunque progetti sono provare a farne con dei team, di fare dei proof of concept, degli esperimenti, quindi non provare a approcciare al classico modo ma fare una spike, questo mi ha aiutato veramente tanto, questo è l'insegnamento che mi porto dietro, fare delle spike sui progetti, piccole time boxate su quello che vogliamo esperimentare, perché? Perché ci dà la possibilità di vedere i pro e i contro di un pattern, di quello che vogliamo.Questo è un insegnamento che mi porto dietro da diversi anni e che mi ha fatto scoprire veramente come riuscire a ridurre quel tempo di learning, quel tempo di riuscire a capire cosa ci serve e cosa no, senza analisi di settimane e mesi che poi ti portano sempre a cambiare le cose in in corso d'opera.Che cose io, analisi così lunghe, non le apprezzo tantissimo ormai più.Preferisco fare una spike di una settimana e mi risolvo i dubbi.Hai tirato fuori due testi sacri dello sviluppo e su questo Carmine lo dico? La dico la mia bold opinion, adesso scatenerò il frame.Allora, io devo dire che quei due libri di "Uncle Bob", "Leoletti", però è da un po' che all'interno degli ammutinati, in realtà due giorni, sono uscito con questa frase per definire Uncle Bob, che è lo zio zittello che quando eri bambino ti portava in giro in moto ed era un figo, ma una volta diventato adulto lo vedi un po' come fuori luogo, anche se quello che ha scritto sono, diciamo, le pietre miliari della nostra programmazione, ma è comunque un po' poco.Mi sta f***ando il bobo, no? Non lo rego, abbiate pazienza, lo devo dire a qualcuno, quindi dirlo ai nostri 600 ascoltatori.Io sono concorrente nel tema, non sono un amante del personaggio, ma Clean Code e soprattutto Clean Architecture sono dei libri che hanno veramente cambiato anche il mio modo di approcciare all'architettura al codice.Quindi ce l'ho anch'io sul comodino Clean Architecture e lo rileggo ogni tanto.E' secondo me un libro fondamentale e secondo me la spiegazione più chiara e più concreta dell'hexagono sta dentro Clean Architecture.Quindi sicuramente li consiglio e sarebbero stati anche i miei balocchi, però insomma ero quasi sicuro che sarebbero stati citati, quindi il mio balocco di oggi è un balocco per la vostra parte infrastrutturale del vostro prossimo progetto in Clean Architecture che è Designing Data Intensive Applications.Ho sempre qui sul comodino che è di Martin Kleppman, non ricordo il nome, ed è un bellissimo Il libro è un libro molto pratico, ma è anche una chiacchierata su come progettare e come approcciare a dei sistemi che sono datacentrici e data intensi.Quindi è un balocco per la parte infrastrutturale della vostra applicazione.occhio, perché il dominio non deve sapere niente, altrimenti c'è qualcosa che non va.L'altro palocco in realtà è una riflessione, nel senso provate ad andare una vostra code base storica e provate a censire tante scelte della vostra business logic, della vostra Logica Core che sono state fatte perché la parte infrastrutturale lo richiedeva.Andate a scienziare quel ciclo for, quel lift strano che avete fatto solo perché stavate ragionando con questo lo faccio con Postgres, questo lo faccio con Elasticsearch, questo lo faccio con Mongo e se ne trovate anche più di una, leggete Clean Architecture e Clean Code.Bellissimo questo.Sai che lo farò davvero? Io invece ho giusto un modestissimo articolo.durante la puntata ho parlato di Functional Core, Imperative Shell e quindi vi condivido la raccolta di contenuti che ho trovato su questo argomento.E' molto interessante, ci sono dei video su YouTube, una serie di articoli, no? Tra l'altro c'è una frase che se adesso la trovo mi ha un po' fatto ragionare che dice "All code can be classified into two distinct roles" Vabbè, il nostro codice può essere classificato in due ruoli distinti il codice che lavora, gli algoritmi, e il codice che coordina il lavoro, che sono i coordinators quindi un altro argomento che si apre proprio partendo dalla hexagonal architecture è "Perché no?" Magari, prima o poi, ci faremo anche una puntata Mamma mia si è fatto tardissimo! Io ormai non capisco più niente visto che sono quasi l'8 di sera e sono non stop da stamattina ma mi ha fatto super piacere avere qua con noi Alessandro, grazie di essere venuto Alessandro grazie a voi veramente è stato piacevolissimo e divertentissimo grazie a te io ringrazio anche Carmine con il quale abbiamo condiviso la nostra birra e vi ricordo rapidamente i nostri contatti info@gitber.it e la nostra mail @brainrepo il profilo twitter che spesso utilizziamo e poi c'è il nostro gruppo telegram basta cercare github siamo quasi 400 e siamo pronti a farci delle grandi chiacchierate proprio su quello che amiamo di più il nostro lavoro se questo episodio vi è piaciuto è naturalmente merito di carmine di alessandro e nulla se vi è piaciuto veramente tanto beh e avete anche un device Apple mi raccomando metteteci una stellina questo ci aiuterà in qualche modo a raggiungere ancora più orecchie e quindi portare ancora più amici all'interno del nostro bar chiamato anche gruppo Telegram.Io credo di aver detto tutto per cui non mi resta che dare appuntamento alla prossima settimana ringraziando nuovamente Alessandro e Carmine da Budoni è tutto alla prossima ciao ciao ciao Gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta delle attrezzi dei Full Stack Dead.[Musica] [Musica]
