Domain-Driven Design: una questione tecnica?
Quarto DDD Open Space: tanti temi e nuove sfide
DDD Open è la community italiana dedicata a Domain-Driven Design.
Uno spazio di discussione libero e partecipativo sul DDD aperto a esperti, neofiti, esploratori.
L’1 e 2 dicembre 2022 è andato in scena il quarto Open Space (da remoto) organizzato dal team DDD Open. Ti raccontiamo com’è andata.
Gli episodi precedenti puoi leggerli seguendo il tag ddd open in questo blog.
DDD Open Space
Un anno dopo la terza edizione di DDD Open Space, abbiamo stimolato la community italiana con la domanda “DDD è solo una questione tecnica?”.
Abbiamo pensato che valesse la pena organizzare una nuova edizione dell’Open Space per portare a galla i temi legati a DDD e il risultato è stato un evento da remoto di due mezze giornate con 50 persone iscritte che hanno portato la propria esperienza.
Anche per questa edizione ci siamo avvalsi di Zoom, Miro e Slack come strumenti per la comunicazione e l’interazione.
Il tema dell’Open Space
DDD - Una questione tecnica?
L’invito
Condividere la propria esperienza su Domain-Driven Design in relazione, in particolare, a Modern Software Architecture e Product Development.
La scenografia
Come da tradizione, anche per questo quarto evento da remoto abbiamo curato l’aspetto scenografico e visuale, andando a visitare alcune delle cime italiane più affascinanti, cercando di unire il nostro paese, dal nord al sud, grazie alle sue bellissime montagne. :)
Com’è andato l’evento
Hanno partecipato all’evento complessivamente 50 persone e sono state proposte più di 20 sessioni.
Al di là dei numeri, è il livello di profondità delle conversazioni che ci ha piacevolmente sorpreso, che ci ha dato la misura più significativa del successo di questa edizione ma in generale di questa iniziativa, e che ci conferma quanto siano importanti i momenti di confronto per supportare la crescita di una community.
Market Place
Le dinamiche di composizione di Marketplace sono state fluide, sia in termini di organizzazione (ha funzionato molto bene il metodo funivia, e il timing) sia in termini di varietà delle proposte.
Un grazie particolare a Matteo Cavucci che ha facilitato questo quarto Open Space.
Sessioni
La durata delle singole sessioni è stata di 45 minuti e di 15 minuti per la Sprint Session (l’ultima sessione del secondo giorno).
Share Back
Al termine di ciascuna giornata, abbiamo dedicato 30 minuti di condivisione collettiva per far emergere cosa fosse stato discusso e approfondito durante le singole sessioni (grazie anche agli scriba, il cui ruolo era quello di prendere appunti sulla board di Miro).
Per ogni proposta sono stati dati due minuti di share back, che abbiamo provato a catturare e vi riportiamo di seguito.
Giorno 1
Cervino
Gran Sasso
2. Da dominio a modello in ambiente legacy - Lorenzo Verri
3. DDD e Soggettività - Claudio D’Alicandro
Gran Paradiso
4. Controllo della transazione e trasparenza - Luca Menghini
5. DDD ES/CQRS e “dettagli” tecnici - Luca Giovenzana
Monte Bianco
6. Refactor di un’applicazione - Alessandro Sarzina
7. EventStorming da remoto: tips and tricks - Pietro Di Bello
Dolomiti
8. DDD in contesti enterprise - Alessio Verdolini; Come diffondere DDD in azienda per usarlo al meglio - Eduardo Silvi; DDD per ambienti già incasinati - Sebastian Magri
9. DDD e TDD, come si interlacciano? - Francesco Mastellone
Giorno 2
Polenta
10. DDD e Organization Design - Ivan Diana; Composizione dei Teams, Processi produttivi, Organizzazione aziendale e DDD - Annamaria Coppola
11. Microservices vs Bounded Contexts: che relazioni ci sono? - Claudio D’Alicandro (Sprint session)
Speck
12. Da dove iniziare? - Marco Loche
13. Preventing bad events - Pietro Di Bello (Sprint session)
Pista Sci
14. DDD, comandi e frontend - Damian Dominella; Tricky Modelling Clinic - Alberto Brandolini
Baita
15. Let’s talk about projections - Emilio Jr Francischetti
16. DDD for Products - Alberto Brandolini
Brauerei
17. Context mapping: how to - Pietro Di Bello
18. DDD, Scalabilità e Manutenibilità - Roberto Colombo
Eventi d’integrazione vs Eventi di dominio - Matteo Galacci
La proposta di sessione è nata da un’esigenza di chiarimento di alcuni dubbi da parte di Matteo Galazzi per quanto riguarda eventi di integrazione vs eventi di dominio.
Nella sessione tutti i partecipanti si sono trovati d’accordo sul fatto che non ha senso parlare di duplicazione: si tratta di uno scambio dati tra bounded context diversi. Sono mondi diversi e le informazioni vanno comunicate.
Approfondendo l’argomento, si è anche discusso di come un evento di integrazione in entrata vada gestito dal servizio che lo riceve, e di come si dirami. Se l’evento viene portato avanti seguendo un approccio CQRS, è giusto che questo segua la catena comando, evento ecc. Se invece questo non avviene, tanto vale averlo dritto nello store.
Una delle massime - ricorrenti tanto in questa sessione quanto nel resto dell’evento - è: DDD costa! Per cui se non serve davvero, non ha senso farlo.
Un’altra osservazione emersa è stata: se arriva un evento di integrazione e non ha valore nel bounded context, lo salvo come modello.
Da dominio a modello in ambiente legacy - Lorenzo Verri
Il contesto è quello di uno sviluppatore che si trova a collaborare con stakeholder molto più grandi di lui. È stato quindi discusso lo scenario, la difficoltà di comunicazione tra sviluppatori, manager e stakeholder, e ne sono uscite alcune soluzioni: quando si discute con stakeholder più anziani, che vedono la tecnologia come un dolore, la prima cosa da fare è ragionare su qual è il valore che porta il software o la soluzione che si sviluppa. Concentrarsi sul valore prima che sulla tecnologia. Poi si possono anche valutare metodi come EventStorming per capire meglio aspetti tecnici e umani (e cercare il confronto). In ultima analisi, è stato suggerito di usare un linguaggio corretto, evitare l’inglese, e allinearsi con ciò che si dice.
DDD e Soggettività - Claudio D’Alicandro
In questa sessione erano presenti tutte persone di una stessa azienda, il che è stato utile per confrontarsi e allinearsi su alcuni aspetti. Tra le altre cose, si è discusso di: granularità dei bounded context, se e come discuterla (e come definirli), quanto sia istituzionale dividere i team di sviluppo per bounded context (o se è arbitrario), se e come fare cherry picking su alcuni principi DDD (per es. quanto è necessario essere a stretto contatto con gli stakeholders).
Controllo della transazione e trasparenza - Luca Menghini
La sessione nasce dall’esigenza di Luca Menghini di chiedere un chiarimento, e confrontarsi su un passaggio del libro blu di Eric Evans, aka il libro da cui inizia il DDD. Il passaggio in questione è contenuto a pagina 152 (capitolo 6):
“Leave transaction control to the client: Although the repository will insert int and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the repository keeps it hands off."
Uno degli spunti emersi è che si può considerare quanto scritto nel libro, datato 2003, ormai obsoleto. È consentito avere il controllo della transazione sul repository, il boundary transazionale dell’operazione è nell’aggregato, il resto sarà “eventually consistent”.
DDD ES/CQRS e “dettagli” tecnici - Luca Giovenzana
La discussione parte dall’esperienza di un’azienda, con alcuni esempi di ciò che loro hanno fatto, alcune conferme e risposte, qualche dubbio.. Da questi spunti iniziali sono nate altre domande.
Una sessione molto tecnica in cui tra le altre cose si è parlato dell’organizzazione di cartelle del progetto (il che nasconde alcuni aspetti su DDD e separazione in bounded context), come mantenere l’ordine, retry e delay dei messaggi, e l’idempotenza.
Refactor di un’applicazione - Alessandro Sarzina
La sessione inizia con la descrizione di uno scenario: quando fare refactor di un’app legacy per introdurre concetti DDD.
La discussione si arricchisce di esperienze personali: chi era partito dai microservizi, chi aveva una codebase legacy (senza test), ecc.
Emerge anche che in alcuni casi può valer la pena introdurre solo alcuni concetti, senza fare una trasformazione radicale, e poi tornando al tema centrale.
Il gruppo si è chiesto: passare al DDD ha sempre senso, o a volte non porta valore? La risposta è stata che prima può avere più senso introdurre modifiche di tipo architetturale (come clean architecture e clean code) per ripulire codice legacy vecchio, e poi suddividere la complessità, o anche solo cambiare il naming di alcune parti di codice.
Un altro tema emerso è stato: se si decide di fare questo tipo di cambio, quando ha senso passare al DDD? La conclusione è stata: dipende dalla maturità del team. Se ci sono dev junior è molto difficile e potrebbe richiedere moltissimo tempo.
EventStorming da remoto: tips and tricks - Pietro Di Bello
Pietro Di Bella ha proposto una riflessione in merito a EventStorming e al passaggio alle attività da remoto in chiaramente alcune cose cambiano la durata delle sessioni, un bisogno maggiore di fare spiegazioni all’inizio della sessione, la perdita della calligrafia di ciascuna persona, ecc (si veda la Board Miro per maggiori info).
Un dato emerso nella conversazione è che Big Picture EventStorming non funziona bene da remoto quanto in presenza, per cui è sempre preferibile farlo in persona.
Quando si fa una sessione di EventStorming da remoto è importante tener conto dell’energia da remoto.
Si è poi affrontato l’argomento attività co-localizzate vs attività in presenza. La modalità da remoto comporta alcuni vantaggi: viene favorita una maggiore interdisciplinarietà, è possibile invitare persone all’ultimo momento, poter confrontare molto velocemente percorsi fatti da persone diverse, poter storicizzare quanto prodotto e renderlo disponibile offline e in modalità asincrona per darlo ad altri (affinché contribuiscano), è possibile continuare a contribuire all’attività anche in momenti successivi.
Come ultimo argomento, si è discusso della necessità o meno di convincere le persone a dover/voler fare EventStorming. Come già detto in mattinata, le persone non vanno convinte: è importante iniziare a fare e, se si teme che il nome di una certa cosa possa creare timore o scetticismo, meglio non chiamare una certa attività col nome della tecnica (leggi: non parlare di “sessione di EventStorming”, iniziare le attività e portare a casa i risultati.
Fondamentale superare il disagio iniziale e favorire la conversazione.
DDD in contesti enterprise - Alessio Verdolini
Come diffondere DDD in azienda per usarlo al meglio - Eduardo Silvi
DDD per ambienti già incasinati - Sebastian Magri
(Le 3 sessioni sono state accorpate in una)
Questa sessione, il risultato dell’unione di tre sessioni simili e che sono state accorpate durante il market place, non è concentrata tanto sulla parte tecnica, quanto sulle domande poste e da porre. Ossia: perché convincere il business, come introdurlo a DDD e come farlo bene.
Poi è scaturita la necessità di definire gli attori nelle organizzazioni: management, business, developer e prodotto.
Secondo Alberto Brandolini, il business in realtà non deve autorizzare il team di sviluppo a fare DDD: DDD deve nascere dal team. Lo si inizia a proporre per avere un caso di successo da replicare e condividere dopo. Il come introdurlo e farlo bene è qualcosa del tipo: partiamo da qualcosa, prototipiamo, raccontiamo la storia e poi eventualmente li convinciamo.
La discussione è stata affrontata più da un punto di vista organizzativo che non tecnico.
Uno dei libri che sono stati consigliati, a fine sessione, è stato Lean Change Management di Jason Little.
Come riassumere questa ricca sessione? Cercare di convincere qualcuno è una perdita di tempo. Piuttosto facciamo, e i fatti parleranno per noi.
DDD e TDD, come si interlacciano? - Francesco Mastellone
La richiesta parte da Francesco Masstellone ed è originata dal fatto che nella sua azienda ci sono stati due cambiamenti comunicativi rilevanti: l’introduzione dell’acceptance testing per la comunicazione tra product people e developers, e poi l’introduzione di DDD. La domanda è quindi: come si interlacciano queste due cose in un contesto ex novo?
È emerso subito che l’interazione è utile per validare il design, che il working code è ciò che interessa di più, e i test devono validare il DDD, anche per smentirlo.
Anche in seguito a una sessione di EventStorming si potrebbe voler ragionare in test BDD (gherkin) e questo già potrebbe invalidare tematiche emerse nel design.
Utilissimo anche imparare che DDD non sia fatto per il big upfront design ma che invece si presti molto all’iterazione.
La discussione è stata molto ricca e ampia, per cui si rimanda alla Miro board per gli approfondimenti.
DDD e Organization Design - Ivan Diana
Composizione dei Teams, Processi produttivi, Organizzazione aziendale e DDD - Annamaria Coppola
(Le 2 sessioni sono state accorpate in una)
Le due sessioni sono state accorpate perché affrontano un argomento simile, introdotto da Annamaria Coppola: c’è un piccolo gruppo di aziende già strutturato per lavorare in DDD dove tutto è già abbastanza pronto e ottimizzato in questo senso. Poi c’è un grande numero di altre aziende, più o meno da Roma in giù, che rappresentano o lavorano con la Pubblica Amministrazione. Il problema è che la PA non è strutturata per DDD e si muove su divisioni molto rigide. Questo rende impossibile posare la prima pietra, ossia fare EventStorming, DDD diventa una cosa tecnica di chi sviluppa, e diventa letteralmente impossibile mettere insieme tutti gli stakeholders.
Un’idea proposta per ovviare a questo problema: mettere su un trio tecnico che va a fare EventStorming a nome del team.
Ivan Diana ha raccontato la sua esperienza all’interno di PagoPA: i team tecnici lavorano per raffinare il processo e applicare DDD e per vedere se la divisione team/bounded context funziona.
Il confronto all’interno della sessione è stato molto interessante, ed è stato ribadito come non serva dover convincere nessuno per iniziare a fare DDD.
Microservices vs Bounded Contexts: che relazioni ci sono? - Claudio D’Alicandro
In poco tempo (le sprint session durano 15 minuti), il gruppo si è interrogato su esperienze in merito alla relazione tra microservizi e bounded contexts.
La riposta più comune? Il classico “dipende”! C’è una correlazione quando lo splitting dei bounded contexts è stato fatto bene, ma si parla di microservizi intesi come una strategia per separare unità di deployment.
Ci possono essere punti di contatto ma sono due concetti che nascono per questioni differenti.
Da dove iniziare? - Marco Loche
La richiesta di Marco Loche su come iniziare ad approcciarsi a una materia per lui nuova come il DDD ha prodotto una serie di suggerimenti utili su come proporre una cosa nuova, impattante e importante ai colleghi del team di sviluppo (non tanto al business).
La cosa migliore, come già evidenziato in altre sessioni prima di questa, è lavorare su una cosa piccola, con poche persone, al fine di mostrare quante cose positive si possono avere utilizzando DDD. In questo modo si parte da qualcosa di concreto per far sì che gli altri si appassionino e abbiano voglia di lavorare in DDD a loro volta.
Preventing bad events - Pietro Di Bello
Altra Sprint Session di 15 minuti per discutere come evitare che un cambio di schema nell’evento pubblicato da un bounded context (evento di integrazione) possa rompere chi già consumava questo evento.
Sono state elencate un po’ di possibilità: i consumer dovrebbero essere in grado di reagire a eventuali cambiamenti di schema nel modo migliore possibile. Nel caso ideale, cercare di adattarsi a qualcosa che non sanno ancora gestire, o comunque non rompersi.
Altra idea è quella di fare un refactoring riparatorio: un evento intermedio che consenta di avvicinarsi incrementalmente al cambiamento.
Oppure un’altra soluzione proposta è quella di aprire una pr sull’event catalog, la app che gestisce i contratti di tutti gli eventi pubblici, e aprire una pr ogni volta che c’è un cambiamento nello schema di un evento.
DDD, comandi e frontend - Damian Dominella
Tricky Modelling Clinic - Alberto Brandolini
(Le 2 sessioni sono state accorpate in una)
La sessione è iniziata analizzando l’esperienza di un’azienda e le difficoltà nel far progredire sugli stessi binari DDD e UI, considerando che quest’ultima è rimasta indietro rispetto alle novità emerse grazie a DDD. Come riuscire a fare interfacciare i due mondi? Altri partecipanti alla sessione hanno presentato altri casi studio e messo a confronto i vari processi adottati.
Un’altra considerazione che è emersa è che la parte frontend dovrebbe essere agnostica rispetto a cosa accade a livello di aggregato. La domanda è dunque: come isolare queste due parti?
La discussione ha portato a molti spunti da cui partire per provare a sperimentare nuovi approcci nei vari contesti presentati dai partecipanti. Rimandiamo alla Board Miro per ulteriori approfondimenti.
Let’s talk about projections - Emilio Jr Francischetti
Emilio Jr Francischetti ha proposto una sessione tecnica per discutere delle projections e quando queste prendano più event store e bounded contexts. L’utente potrebbe aver bisogno di info da modelli differenti. Le possibili soluzioni: event store comuni che ricevono gli eventi di integrazione, quindi si può lavorare su quelli, ma questo aumenta lo storage del 30-40%. Un’altra possibile soluzione è Atom Feed, una tecnologia che viene dal passato: un feed rss che ti restituisce tutto quello che è uscito da altri bounded context.
Una sessione molto ricca, per scoprirne di più rimandiamo alla Board Miro con gli appunti.
DDD for Products - Alberto Brandolini
La sessione è iniziata raccogliendo i pain point dei partecipanti quando si parla di DDD per prodotti, per poi parlarne.
Partiti cercando di vedere una mappa del territorio, consapevoli che non avremmo fatto tutto.
Il risultato: è immediatamente necessario capire quanti sono i clienti, chi è il buyer, se parliamo di b2c o b2b, ecc., perché cambiano i rapporti di forza.
Ci si è posti domande quali “chi comanda? Sto imponendo il prodotto al mercato, con singoli utenti, o a organizzazioni più grosse?”
Sono emersi i problemi della gestione della comunicazione (e i suoi canali): in DDD questo canale è interno, ma poi si va a sovrapporre con stakeholder/utenti/esperti (esternamente).
Invece in un sistema a prodotto devi gestire questi canali e la molteplicità di utenti, e ogni organizzazione/prodotto ha la sua forma (questo è l'elemento più complesso da gestire).
È complesso anche il rapporto con la parte di engineering: ci sono molte scelte sbagliate che violano l’integrità del nostro design… anche se l’integrità del design è proprio l’arma di sopravvivenza per il futuro.
A tal fine è utile accorciare la catena e avere anche rappresentanti di engineering a fare scelta di prodotto.
Un altro elemento da tenere a mente è la possibilità di fare scommesse sapendo di perdere, il che ha un costo di rinuncia basso per il futuro.
Context mapping: how to - Pietro Di Bello
Nella sessione proposta da Pietro, EventStorming è un ottimo strumento per identificare i bounded context nella context map. Anche ascoltare le inconsistenze linguistiche è un ottimo indicatore per capire dove sono i bounded context.
La sessione è continuata parlando di EventStorming: a volte è difficile partire perché se si usa EventStorming, questo può risultare difficile da proporre rispetto ad altro. I motivi? Se si vuole vendere per convincere qualcuno - è praticamente impossibile. O si usano tecniche dove semplicemente si porta la gente a fare le cose davanti a una board senza chiamarlo EventStorming, o si parte dai pain point dei team: quali e dove sono i punti di difficoltà, le frizioni, per poi identificare boundaries che non sono molto precisi.
Un’idea e un modo utile di usare la context map è anche quella di farne una dell’as is e una del to be.
La sessione si è conclusa rilevando che la context map è uno strumento sottovalutato e poco usato.
DDD, Scalabilità e Manutenibilità - Roberto Colombo
La discussione parte dal racconto dell’esperienza in azienda: appena finita una migrazione e sull’event store (che gestisce tesserati a club sportivi) ci sono un milione e mezzo di eventi. Il che porta a molta preoccupazione sull’evoluzione della cosa.
Tra le soluzioni proposte:
- l’event store non è intoccabile (sola scrittura), per cui si possono spostare i singoli eventi (l’importante è non alterare l’evento in sé);
- per quei flussi di eventi che si auto chiudono (come una spedizione), quegli stream possono essere spostati dall’event store principale;
- copy/replace (come insegna Greg Young): per ogni singolo aggregato si può “riscrivere una storia”, per esempio sommando eventi che possono essere collassati;
- collassare eventi transazionali che fanno somme o movimenti, questi possono essere condensati grazie all’aggiunta di un evento.
Prossimi appuntamenti e segnalazioni
Se ti interessa seguire le conversazioni della community DDD Open, ti segnaliamo questi canali:
Twitter
Linkedin
Youtube
Slack
Il prossimo evento sarà disponibile sul sito DDD Open.
Libro DDD in italiano
Ti segnaliamo il libro Cronache di Domain-Driven Design, scritto da Alberto Acerbis, Matteo Baglini, Uberto Barbini, Alberto Brandolini, Alessandro Colla, Marco Consolaro, Emanuele DelBono, Gianluca Padovani,Francesco Strazzullo, disponibile su Leanpub in versione digitale e Amazon in versione cartacea.
Restiamo in contatto :)
Vuoi continuare a leggere le cose che pubblichiamo? Iscriviti alla nostra Newsletter 📩.
Ti faremo compagnia ogni venerdì mattina. ☕️