Go meetup #18

**Ospitato da Pure Storage**

Tieni presente che presso l'ufficio Pure Storage tutti i partecipanti al meetup dovranno firmare un NDA generico utilizzato per consentire a tutti i visitatori dell'ufficio di partecipare al meetup.
Le porte saranno aperte dalle 17:30, i colloqui inizieranno alle 18:00 e avremo 3 colloqui.

**1\. Vilibald Wanča \(Pure Storage\)\, Introduzione all'architettura basata su celle**

**2\. Miłosz Smółka\, Killing the legacy e altre storie del CQRS**
Conosci la sensazione quando il tuo progetto si blocca e non riesci ad andare avanti? Vedi alcune vie d'uscita, ma sembrano tutte ugualmente negative. Inizi a chiederti se il progetto è destinato a fallire o se semplicemente ti mancano alcune conoscenze speciali. L'ho sentito maggiormente mentre cercavo di uscire dai sistemi legacy, ma è comune in molti progetti.
Col tempo, ho imparato che cambiare il tuo modello mentale può rivelare una soluzione che non vedevi prima. Ripensando ad alcuni dei miei progetti, mi sono reso conto che uno dei modelli che mi ha aiutato a pensare diversamente è stato CQRS. Non importa se hai già utilizzato CQRS, poiché non ho intenzione di annoiarti con definizioni astratte. Molto è stato detto sulla teoria del CQRS. Voglio invece mostrare come l'ho usato nella pratica. Condividerò tre storie vere di diverse aziende e progetti in cui sono riuscito ad andare avanti e comprendere meglio CQRS. Uno di questi è stato il più impegnativo: eliminare il codice base legacy.

**Bioografia:** Miłosz Smółka scrive di Go, un moderno software aziendale e di argomenti correlati su [https:// Threedots.tech](https://Threedots.tech/). Gli piace condividere ciò che ha imparato lavorando in startup e costruendo prodotti in diversi campi.

**3\. Robert Laszczak\, Ripensare la progettazione basata sui domini in Go: dai miti alla riduzione della complessità del progetto**
Suddividere i problemi in problemi più piccoli può essere una buona strategia per affrontare problemi complessi. Ma a volte, invece di velocizzare lo sviluppo del progetto, accade il contrario. In definitiva, lo sviluppo della funzionalità più semplice richiede il lavoro eroico di 10 team su una dozzina di microservizi nell’arco di sei mesi. Sembra familiare?
"Divide et impera" non è l'unica strategia che possiamo attuare in progetti complessi. Uno degli approcci più consolidati in grado di semplificare l'implementazione di funzionalità con logica di dominio complessa è il Domain-Driven Design (DDD).
Ho trovato DDD molto utile in più progetti con domini complessi su cui potrei lavorare. D'altro canto, so che le persone credono in molti miti sul DDD utilizzato nel Go. La maggior parte di essi deriva dall'utilizzo del DDD in progetti che non richiedono un approccio così sofisticato o da progetti implementati da persone che non comprendono i principi del DDD.
Durante questo discorso, demistificherò i DDD e vi fornirò un esempio reale di come il potenziamento dei DDD abbia contribuito a semplificarli e ad aumentare la velocità di sviluppo.
Se al momento non lavori su un progetto con una logica di dominio complessa, questa presentazione potrebbe comunque esserti utile se desideri lavorare su progetti più impegnativi in ​​futuro. Ti darò anche alcuni suggerimenti su quali parti di DDD dovresti iniziare e quali tecniche funzionano bene con DDD.

**Biografia:** Sto scrivendo sul blog threedots.tech. Autore di "Go With The Domain" e [Watermill.io](https://watermill.io/).
Il mio percorso di programmazione dura da 16 anni, durante i quali ho esplorato diversi ambiti, tra cui infrastrutture, piattaforme finanziarie globali e sicurezza. Un paio di anni fa ho finalmente trovato una lingua che amavo: il Go.