Domain-Driven Design per Non-Tecnici

Intervista con Julie Camosseto e Uberto Barbini


Di seguito pubblichiamo integralmente il capitolo DDD per Non-Tecnici, tratto da Cronache di Domain-Driven Design, un libro pubblicato da Avanscoperta che contiene otto storie a tema DDD.

Come tutte le storie del libro, si tratta del racconto di un caso di applicazione di DDD nel lavoro di tutti i giorni delle persone, nello specifico di una chiacchierata tra Julie Camosseto e Uberto Barbini dove si parla di come DDD è stato utilizzato per riordinare il catalogo di una casa editrice accademica.

Chi ha detto che DDD è solo per tecnici? ;) Buona lettura!


Ci presentiamo: siamo Julie e Uberto.

Julie Camosseto lavora in IT da più di venti anni, ed è Programme Manager freelance. Ha un background in Object-Oriented Analysis, metodologie agili e architettura enterprise. Ed è anche Life Coach certificata.

Uberto Barbini è un programmatore con una discreta conoscenza di svariati linguaggi, architetto software con tanti (troppi) anni di esperienza nello scrivere software per aziende di tutte le dimensioni - da micro-aziende a multinazionali - e con la voglia di usare DDD il più possibile. È anche uno speaker internazionale e autore di diversi libri.

Abbiamo lavorato insieme per una prestigiosa casa editrice accademica, rimettendo in sesto un vasto programma di pubblicazioni, programma che era cruciale per rimanere leader nel settore Open Access. Vogliamo condividere qui come DDD ed EventStorming siano stati essenziali per permetterci di completare una serie di progetti in un lasso di tempo molto ristretto, tanto che si credeva non fosse possibile.

DDD è considerato generalmente un argomento per software developer. Ma in realtà, adottare DDD porta diversi benefici a tutto il team, e non dovrebbe essere limitato agli sviluppatori. Tutti i ruoli in un team, compresi manager e clienti (stakeholders), possono beneficiarne.

Ma cosa intendiamo con DDD per non-tecnici? Quello che intendiamo è estendere le pratiche di design e comunicazione di DDD anche al top management e ai clienti, coinvolgendoli nella definizione della soluzione e nel suo progressivo sviluppo. Nella chiacchierata che segue, raccontiamo la nostra esperienza.

Una chiacchierata tra uno sviluppatore e una Programme Manager

Uberto: Julie, ti ricordi come iniziò il progetto?

Certamente! Il nostro cliente stava cercando di rimanere leader nel mercato delle case editrici accademiche, il che richiedeva di doversi adattare rapidamente a un nuovo modello chiamato Open Access. Le pubblicazioni Open Access rendono le ricerche e i giornali scientifici disponibili gratuitamente al pubblico e agli altri ricercatori, senza doversi abbonare. Il processo è finanziato direttamente dall’autore che paga il costo di pubblicazione senza altri oneri o, come capita di solito, da un accordo tra la casa editrice e le varie istituzioni, come università e consorzi.

Questi accordi permettono di ottenere un cash-flow più stabile per la casa editrice, un’amministrazione semplificata per le istituzioni e una migliore esperienza per gli autori.

L’organizzazione interna del nostro cliente era il risultato della fusione di tre grandi aziende dodici anni prima. Di conseguenza, i sistemi IT e i processi di business non erano ancora del tutto integrati, e anzi erano diventati molto difficili da cambiare.

Nel corso dei precedenti due anni, il cliente aveva fallito due tentativi di aggiornamento dei processi di pagamento e pubblicazione al fine di integrare i contratti Open Access. Nonostante il grosso lavoro e gli sforzi di tutte le persone coinvolte, sembrava che nessun progresso fosse stato fatto in due anni. Come risultato il top management aveva iniziato a perdere fiducia nel reparto IT e tutte le persone coinvolte erano molto stressate.

Questa era la situazione quando noi siamo arrivati. La nostra responsabilità era di riportare il programma sulla giusta rotta e di creare un sistema integrato per raccogliere i pagamenti, le informazioni di copyright, e fornire una migliore reportistica finanziaria.

La nostra prima analisi strategica con il CTO e il VP di business operation diede come risultato una stima di consegna di circa diciotto mesi.

La settimana dopo aver stabilito questa stima, mentre stavamo organizzando i team per iniziare l’implementazione, ci dissero che il cliente stava negoziando un contratto con il più grande consorzio di istituzioni in Europa. Questo accordo avrebbe dato accesso a tutti i giornali del nostro cliente (diverse migliaia) e a tutti i ricercatori delle istituzioni del consorzio, oltre che a permettergli di pubblicare in modalità Open Access.

Questo avrebbe comportato modifiche di molti più sistemi di quelli considerati inizialmente, e avrebbe escluso una delivery progressiva, in quanto l’accordo avrebbe compreso tutti i giornali fin dall’inizio.

La notizia ci arrivò all’inizio di febbraio del 2019, proprio mentre l’architetto e i responsabili di prodotto e management stavano per andare a fare un tour di due settimane in India per incontrare il resto del team di sviluppo. Ci dissero che questo accordo era cruciale per la sopravvivenza stessa dell’organizzazione e che era già stato firmato con la condizione di iniziare a luglio dello stesso anno!

Improvvisamente ci trovammo a dover consegnare una soluzione in cinque mesi per uno scope maggiore della nostra stima iniziale di diciotto mesi. Come spesso succede, il top management riteneva che questo accordo richiedesse solo modifiche molto semplici e si trattasse solo di aggiungere qualche checkbox nell’interfaccia utente per abilitare il deal!

Dopo frenetiche videochiamate con tutti i team di sviluppo in tre continenti, considerata la difficoltà del compito e il tempo limitato, fu deciso di proporre la creazione di un “Tiger Team” al consiglio di amministrazione dell’azienda. Questa opzione era così drastica che eravamo convinti che il top management avrebbe fatto marcia indietro, deciso di cambiare i termini del contratto, e che noi saremmo potuti tornare ai nostri piani iniziali. Anche il nostro immediato superiore disse: «diranno di no, e noi continueremo a seguire il nostro piano».

L’idea dietro il Tiger Team era quella di creare un team speciale, mettendo insieme membri di tutti i team coinvolti nella trasformazione, facendoli lavorare nella stessa stanza con pieni poteri per scavalcare qualsiasi altra regola aziendale e con precedenza assoluta rispetto a tutti gli altri progetti aziendali. Il termine è utilizzato nell’esercito americano e fu reso famoso dalla NASA che adottò un Tiger Team per risolvere i problemi della missione Apollo 13 nel 1970.

Per noi significava avere nella stessa stanza sviluppatori e responsabili del sistema di pagamenti SAP, del processo di pubblicazione, del reparto legale, ecc. In questo modo qualsiasi chiarimento o modifica necessari per integrare i sistemi si sarebbe potuta discutere immediatamente de-visu con i rispettivi esperti. Senza bisogno di convocare meeting, senza discussioni in video chiamata o negoziazione delle priorità e tutti i normali attriti del “Business-As-Usual”. Avrebbe anche comportato prendere possesso di una grande sala di solito riservata alle riunioni del board e portare a Londra molte persone dal resto dell’Europa e dall’India per mesi.

Il giorno seguente il CTO ci pensò per poco più di trenta secondi dopo che gli presentammo l’opzione, e infine disse: «ok, andiamo avanti col Tiger Team, non abbiamo scelta. Abbiamo bisogno della soluzione funzionante per la fine di luglio».

Julie: Uberto, quale fu la tua reazione a questo annuncio?

A dire il vero, la mia prima reazione fu: “ok, questa è una di quelle ‘finte scadenze’ che a volte i manager usano per spaventare gli sviluppatori se pensano che non stiano lavorando abbastanza seriamente”. Pensavo fosse impossibile che un’azienda di queste dimensioni e reputazione potesse essersi impegnata in un contratto così oneroso. Ma quando accettarono l’idea del Tiger Team, capii per la prima volta che erano veramente seri e che questo accordo era veramente cruciale per l’azienda. Dissi a me stesso: “Oh perbacco! - per usare un eufemismo - Qui dobbiamo finire questo lavoro sul serio!”.

A quel punto le cose diventarono, come dire, interessanti. Dovevamo consegnare il software per gestire un processo completamente nuovo in pochi mesi, e nessuno sapeva esattamente quali fossero i dettagli. Sarebbe stato un disastro in un’altra azienda o con un altro team, ma avevo grande fiducia nelle capacità del nostro team e in quelle di gestione di Julie e del nostro architetto.

In quanto responsabile del funzionamento della parte tecnica, mi assicurai subito che gli sviluppatori capissero che non avremmo abbassato gli standard di qualità “per raggiungere la scadenza”. Al contrario, li avremmo alzati! Ci saremmo concentrati per cercare di scrivere meno codice possibile. Meglio consegnare poche funzionalità rozze ma perfettamente funzionanti che lasciare cose funzionanti a metà. Per fortuna avevamo il pieno appoggio del management su questo.
Non fu facile spiegare però questo modo di lavorare ai membri più junior del team, specie quelli provenienti da altre culture, abituati a scrivere molto codice in fretta per risolvere ogni problema. Noi chiedevamo, al contrario, di fermarsi e pensare a soluzioni che non necessitassero di alcuna riga di codice. Per questo motivo abbiamo anche usato molto pair programming e mob programming.

Lato business, erano tutti consapevoli della difficile situazione e, nel corso di tutto il progetto, sono sempre stati molto solidali e comprensivi. Ci siamo imbattuti in molti problemi ma siamo sempre riusciti a trovare delle soluzioni lavorando insieme, invece di cercare di scaricare le colpe a vicenda. Grazie a questa collaborazione abbiamo scoperto molti workaround temporanei e soluzioni manuali per gestire i casi più difficili e rari, la cui soluzione spesso richiede la maggior parte del tempo di sviluppo.

In questo modo ci siamo concentrati sui nuovi componenti assolutamente necessari e siamo riusciti a scriverli in tempo applicando i principi di DDD e TDD. Ossia mantenendo la qualità costante, in modo da poter sempre essere in grado di cambiare il codice ogni volta che scoprivamo nuovi requisiti.

Una volta passata (all’ultimo minuto) la scadenza con un sistema funzionante, abbiamo iniziato ad aggiungere le funzionalità mancanti per gestire tutti i casi che avevamo lasciato indietro, man mano liberando il team di supporto dal lavoro manuale.

Penso che aver usato DDD, sia per la parte tecnica che per coinvolgere il business e il top management fin dall’inizio nello sviluppo, sia stato un fattore chiave per il nostro successo.

Uberto: Julie, qual è stata per te la cosa più importante da stabilire all’inizio?

Per me, la cosa più importante è stata concentrarsi su tre aspetti: portare le persone giuste a uno stesso tavolo per creare un team in breve tempo, costruire un buon rapporto con i responsabili del business, e infine raggiungere una comprensione comune dei problemi e delle sfide che ci aspettavano.

Ci era stata data carta bianca per formare il nostro team, scegliendo dagli uffici dell’azienda in tre continenti. C’erano sviluppatori provenienti dai diversi sistemi coinvolti, analisti di business, tester, ma anche i futuri utenti del nostro software e i loro responsabili. Con non poche difficoltà, anche due utenti entrarono ufficialmente nel team e sedevano nella stessa stanza con noi tutti i giorni. È così che abbiamo creato un team globale che comprendeva tutte persone con competenze utili al progetto.

E proprio mentre cercavamo di capire come portare a Londra persone provenienti dall’India, la Germania e gli Stati Uniti, ci rendemmo conto di aver bisogno di uno spazio grande abbastanza per ospitare tutti. Ci serviva una “war room”. La stanza più grande degli uffici di Londra era proprio la boardroom. Ricordo di aver passato un giorno al telefono dall’India (dove stavo ancora facendo la mia presentazione al team) per cercare di convincere i vari membri della board e i loro assistenti che avremmo avuto bisogno della loro stanza per tre mesi. Come potete immaginare non fecero salti di gioia all’idea di spostare i meeting di tutto il top management in una stanza più piccola. Questo creò un certo scalpore e aumentò ancora l’attenzione del top management verso il nostro progetto.

Alla fine il team riuscì a portare tutto l’equipaggiamento (computer, whiteboard, cancelleria, ecc.) di cui avevano bisogno nella nuova “Tiger Room”. Eravamo pronti a partire!

Ma la storia riguardo a quella stanza non era ancora finita: la boardroom era situata nel seminterrato dell’edificio principale e per questo, fin da subito, non piacque a nessuno perché non aveva finestre. Dopo poco il team, infatti, chiese di tornare nell’edificio separato del vecchio ufficio, che invece era molto luminoso. Mi lasciai quindi alle spalle tutti gli sforzi che avevo fatto per assicurarmi quella stanza, e mi focalizzai di nuovo nel trovare un’area abbastanza grande per ospitare tutto il Tiger Team nell’edificio luminoso. Dopo un’intensa negoziazione con i responsabili della logistica, e spostando un paio di piccoli team, riuscimmo a ottenere una grande area luminosa nel nuovo edificio. In questo modo riuscimmo anche ad avere più spazio per i membri del team, che continuava a crescere, e più muri disponibili per le whiteboard su cui tenevamo traccia visualmente del nostro progresso e dell’architettura. Così, durante la fase di discovery, ci furono due mezze giornate interamente dedicate al trasloco, prima in una direzione e poi in quella opposta.

Costruire un rapporto col top management e i nostri sponsor permise al nostro piano d’azione di restare bene in vista ai livelli alti della gerarchia. In questo modo ci fu possibile essere completamente trasparenti con i nostri progressi e mantenere tutti aggiornati continuamente.

Da un punto di vista non tecnico, DDD fu cruciale in questo: il passo successivo fu distribuire a tutti i dirigenti coinvolti a vario titolo i report e i diagrammi con le informazioni che avevamo man mano raccolto riguardo al dominio. In questo modo i dirigenti poterono prendere rapidamente decisioni consapevoli di ogni ostacolo. Inoltre pose le basi per quello che poi sarebbe stato il progresso sullo stato della soluzione che stavamo costruendo. Un primo risultato ottenuto fornendo a ogni reparto una prospettiva che fosse di interesse per loro, con sufficienti dettagli per sentirsi sicuri della capacità di consegna della feature del nostro team.

Il grande vantaggio del Tiger Team è stato sgretolare “silos” di politica aziendale e portare le persone a lavorare insieme. La nostra prima grande attività fu un “Big Picture” EventStorming workshop. Un’attività a grande impatto grazie alla quale si videro le divisioni tra silos scomparire, man mano che i post-it delle varie persone si spostavano da una parte all’altra.

In quel primo EventStorming emersero tutte le differenti opinioni su come risolvere il problema di gestire il “grande accordo” in tutti i vari sottosistemi dell’azienda. Finalmente iniziò a essere chiaro che cosa era necessario fare.

Man mano che emergeva la “big picture”, ci rendemmo conto che c’erano anche dei “buchi” nella serie di eventi descritti dagli esperti di dominio. Mettendo i post-it sul muro della board-room, in modo che riflettessero il processo di pubblicazione di un paper accademico, notammo aree con informazioni incomplete o persino contraddittorie. Nacquero subito conversazioni tra sviluppatori, esperti di dominio e business management su come colmare questi buchi.

Queste conversazioni furono molto utili, non solo per chiarire meglio il problema, ma soprattutto perché misero in stretto contatto il team di sviluppo con gli altri attori coinvolti. Così il team iniziò subito a migliorarsi e a lavorare meglio insieme. Man mano che le discussioni proseguirono, si resero evidenti differenze nel linguaggio usato, in questo modo iniziò l’adozione di un Ubiquitous Language e la scoperta di differenti Bounded Context nel nostro dominio.

Da quel grande EventStorming, iniziammo a vedere quale sarebbe potuto essere il processo da seguire e cosa serviva fare. Capimmo anche che, per fortuna, non tutto richiedeva di essere rifatto da zero subito.

Quando abbiamo iniziato, ci siamo trovati di fronte un’enorme massa di problemi interconnessi: EventStorming ci ha permesso di iniziare a disaccoppiarli, e grazie anche al lavoro sull’architettura software, siamo stati in grado di consegnare la soluzione tagliando porzioni verticali. In altre parole abbiamo iniziato subito a rilasciare un sistema che risolveva una parte del problema - dieci per cento degli articoli (per dire) - e da lì ogni giorno abbiamo aumentato la percentuale di articoli supportata.

Un altro effetto benefico è stato che, vedendo fin da subito qualcosa di funzionante, abbiamo guadagnato la fiducia del resto delle persone di business coinvolte. Finalmente, dopo due anni di grandi piani finiti nel nulla, potevano vedere qualcosa di concreto. E le cose hanno iniziato a migliorare da quel momento.

Julie: Uberto, cosa ne pensi del primo EventStorming e della War Room?

In realtà, proposi l’idea di fare un EventStorming quasi per gioco durante un pranzo con dei colleghi. Quello che non mi aspettavo fu che tutti quanti furono subito molto interessati e vollero provare. Nel passato avevo faticato non poco per convincere colleghi e manager a usare questo formato. In questo team mi limitai a un minimo di facilitazione, visto che erano già tutti entusiasti dell’approccio.

Aver riunito tutte le persone coinvolte nella stessa stanza, incoraggiando tutti a contribuire al nuovo processo insieme, attaccando post-it sul muro con EventStorming, contribuì a formare una base sicura di collaborazione e buona volontà tra tutti gli attori coinvolti. Forse furono questi i maggiori benefici di quel primo workshop, considerando che il diagramma iniziale non durò poi molto. Man mano che ci lavoravamo, scoprimmo molte differenze tra come le cose funzionavano in realtà e come gli esperti pensavano funzionassero.

Tutto sommato comunque, come primo tentativo, andò abbastanza bene e fu molto utile.
Con il senno di poi, infatti, ci rendemmo conto di aver completamente tralasciato due sistemi critici perché le persone responsabili non erano state invitate in quanto tutti pensavano non fosse necessario integrarsi con loro. Questo diventò un problema successivamente, ma così imparammo la lezione che è meglio assicurarsi due volte che non ci siano “buchi” nella comprensione della “big picture” e di invitare anche i sistemi toccati solo leggermente dal processo.

D’altra parte, usammo EventStorming diverse volte in seguito, per disegnare specifici flussi di business, migliorando man mano la facilitazione dei workshop. Alla fine diventarono una routine: facevamo un po’ di foto con gli smartphone e poi traducevamo velocemente il tutto in diagrammi su Miro (uno strumento che permette di lavorare su lavagne online in maniera collaborativa). In questo modo tutti potevano accedere ai diagrammi aggiornati ogni volta che c’erano dubbi, e furono tenuti aggiornati online a ogni cambiamento.

Un vantaggio inaspettato fu che, in questo modo, Julie fu in grado di usare i diagrammi reali (invece che dei powerpoint semplificati) quando discuteva con il top management e i responsabili del business riguardo a date di consegne e feature richieste, rendendoli partecipi dello sforzo del team e aiutando a gestire le loro aspettative.

Uberto: Julie, secondo te qual è stato il maggior beneficio apportato dall’adozione di Domain-Driven Design?

Adottare DDD a tutti i livelli ci diede diversi vantaggi, ma probabilmente il maggiore fu il poter gestire una conoscenza del dominio frammentata, incompleta e a volte anche contraddittoria, distribuita tra i vari “silos” dell’organizzazione.

DDD per noi ha significato cercare una comprensione comune del contesto e dei problemi associati. Determinare un Ubiquitous Language fin dal primo EventStorming ha semplificato la comunicazione e migliorato l’efficienza a tutti i livelli. Per esempio ci siamo resi conto che uno stesso gruppo di giornali era chiamato con due nomi differenti da reparti diversi e non c’era chiarezza su quali giornali effettivamente ne facessero parte!

Inoltre il team commerciale non aveva una chiara idea di cosa il sistema attuale supportasse, e ciò comportò la rinegoziazione delle scadenze per tutte le feature che il sistema attuale non permetteva di gestire. La fondazione di una conoscenza del dominio condivisa almeno permise di ridurre questo genere di problemi in futuro.

La presenza dei direttori di Finance e Marketing fu anche utile per creare una relazione più stretta tra il business e i team IT: in questo modo IT poteva diventare la colonna portante che sosteneva lo sforzo commerciale, invece di essere visto solo come un ostacolo.

Tornando al nostro primo EventStorming, analizzando il flusso di eventi nella Big Picture, fu evidente che non c’era la necessità di scrivere un sistema nuovo che gestisse tutti i tipi di contratti e di riviste fin da subito. Avremmo potuto costruire i pochi pezzi assolutamente necessari per consegnare una soluzione funzionante a luglio (la nostra scadenza) e adattare l’esistente in qualche modo, lasciando alcuni giornali minori con una gestione manuale. Dopo luglio, avremmo continuato a costruire il resto della soluzione finale, integrando i componenti iniziali in una soluzione completamente automatizzata e unificata.

Dalla mia posizione di Programme Manager, ho iniziato a osservare chi tra i vari attori iniziò a prendersi la responsabilità dei vari moduli e delle varie attività. Questi erano già una prima approssimazione dei Bounded Context che poi avremmo usato sia nel codice che per gestire la struttura di comunicazione.

Ma la prima sfida fu senz’altro quella di riuscire a onorare il grande accordo per luglio, fornendo una soluzione, seppure provvisoria, per gestire tutti i gruppi di giornali coinvolti nell’accordo: poco più di tremila testate!

Partendo dai sotto domini che avevamo individuato, discutemmo le priorità con il team. Iniziammo a lavorare solo su tre aree:

1. mettere in piedi un Anti-Corruption Layer (ACL) tra il nostro dominio e il resto dei sistemi aziendali, in particolare quello finanziario/contabile. In questo modo non avremmo dovuto preoccuparci di tutte le strane regole del sistema finanziario dentro al nostro dominio. La nuova semplice interfaccia dell’ACL avrebbe racchiuso tutta la logica dentro di sé;

2. costruire un nuovo sistema di pagamento per gli articoli compresi nell’accordo. Questo sarebbe diventato parte della soluzione finale, quindi dovevamo fare attenzione a non limitare le opzioni future.

3. costruire un componente che avrebbe intercettato gli articoli (che ricadevano dentro l’accordo), dirigendoli nuovamente al nuovo sistema di pagamento e poi riportandoli nel sistema normale come “già pagati” una volta processati. Questo componente avrebbe processato sempre meno giornali man mano che la nuova soluzione avesse gestito più casi, e per essere infine eliminato. E lo fu effettivamente due anni dopo.

Lavorando sempre a stretto contatto con gli utenti, riuscimmo a evitare la sindrome da “Jira Factory”: quando i ticket interni uccidono la comunicazione e si perde di vista il prodotto finale. Noi invece lavorando in stile Kanban e tenendo il backlog al minimo riuscimmo non solo a mantenerci agili ma anche ad arrivare a un approccio olistico verso le necessità del business e dei team di sviluppo.

Quello che intendo è che rispetto ad altri progetti (anche agili) in cui abbiamo lavorato, si notava subito una differenza nel processo di sviluppo. Tipicamente ogni requisito inizia da discussioni astratte con gli esperti di business, che poi vengono trasformate in ticket da dare agli sviluppatori, che svilupperanno il loro domain-model e poi rilasceranno in modo più o meno frequente. In questi casi, il sistema di ticketing diventa il punto di comunicazione centrale tra tutti gli attori coinvolti.
Nel nostro progetto, invece, c’era un’elevata visibilità delle due o tre funzionalità su cui ci stavamo concentrando tutti, e ogni figura era coinvolta fin da subito.
Inoltre, continuando a focalizzarci sul risultato, il sistema di ticketing era relegato a poco più che uno strumento tecnico per tenere insieme vari documenti e tenere traccia della storia, invece di essere quello che dà il ritmo a tutto lo sviluppo.

Julie: e per te Uberto, quali benefici portò l’uso di DDD nel nostro progetto?

Pur avendo usato DDD per molti anni in diversi team come strumento di sviluppo, questa fu per me la prima volta che lo usai a tutti i livelli: dalle discussioni con i manager, alla definizione dei requisiti, fino al codice.

Questa fu un vera rivelazione per me: vedere gli stessi concetti usati e ripresi nelle riunioni a tutti i livelli e poi tradotti direttamente in codice è stato veramente istruttivo. In questo modo fummo in grado di procedere molto più speditamente e risparmiare tempo e frustrazioni dovute a fraintendimenti. In alcune occasioni fui persino in grado di mostrare direttamente pezzi di codice di produzione alla riunione con gli utenti di business per validare la logica e discutere cambiamenti.

Fu anche molto più facile gestire le aspettative del top management perché potevano vedere i progressi in concreto e capire tutto lo sforzo che c’era dietro. Inoltre la continuous-delivery faceva sì che alcune piccole modifiche potessero essere viste in produzione qualche ora dopo averle discusse: una totale novità per loro!

In questo progetto, come spesso capita nei progetti che devono rimpiazzare un processo esistente e interagire con sistemi legacy, l’ostacolo maggiore fu la scoperta e la gestione di un gran numero di casi speciali. Il fatto di condividere la nostra conoscenza di dominio direttamente con gli utenti e gli esperti di business ci permise di far rientrare molti di questi casi speciali in regole generali e gestire gli “irriducibili” rimanenti con soluzioni manuali o semi-manuali.

Il fatto di tenere tutto allineato permise a Julie di usare gli stessi diagrammi di stato usati dagli sviluppatori per le riunioni con gli stakeholder, così da dar loro un feedback visuale delle complicazioni dovute a regole speciali ed eccezioni varie, facilitando il suo compito di mantenere il progetto entro le scadenze. Inoltre, usando gli stessi diagrammi, quando servivano nuove modifiche queste potevano essere velocemente riportate al team di sviluppo.

Abbiamo imparato che per creare un utile linguaggio comune (il famoso Ubiquitous Language) occorreva partire dal linguaggio del business, ma questo non era abbastanza. Fu necessario, infatti, creare nuovi termini laddove la precisione non era sufficiente per permettere agli sviluppatori di scrivere codice.
Per esempio, a un certo punto fu chiaro che reparti diversi usavano lo stesso nome con due significati diversi. Se da un lato questo indicava chiaramente l’esistenza di un Bounded Context, dall’altro spesso ostacolava la comunicazione tra i due reparti. Aver introdotto termini più precisi non solo aiutò gli sviluppatori, ma migliorò anche il flusso di informazioni dell’azienda.

Il nostro approccio a ogni ostacolo - e ce ne furono molti - fu di non cercare di nascondere le nostre difficoltà agli altri team, ma al contrario di cercare soluzioni tutti insieme, e mantenere tutti aggiornati sullo stato corrente della soluzione. Questo portò anche gli altri team a essere più trasparenti e, dopo qualche tensione all’inizio, aumentò la fiducia tra i vari reparti dell’azienda.

Dal canto loro, i responsabili dello sviluppo dovettero imparare che era loro diritto cambiare idea quando imparavamo qualcosa di nuovo, ma non prima! Dovemmo combattere molte volte la loro tendenza nel richiedere soluzioni super dettagliate e poi cambiare idea prima ancora di vederle funzionare. Erano abituati che qualsiasi cosa non venisse inclusa nella prima specifica avrebbe richiesto moltissimo tempo per essere rilasciata.
Invece noi volevamo una prima specifica minimale, per rilasciare subito in produzione un prototipo (nascosto agli utenti normali), e poi migliorarlo e discutere nuove feature insieme fino a quando venisse ritenuto pronto per il pubblico. Anche una volta rilasciato, era sempre possibile cambiare la user experience e aggiungere nuove funzionalità. Fu una rivoluzione di 180 gradi per molti utenti.

Lavorare in questo modo, oltre a essere più gratificante per tutti, ebbe anche il vantaggio di aumentare la produttività in quanto molte feature complesse ritenute indispensabili all’inizio furono poi abbandonate in favore di soluzioni più semplici.

Se avessimo cercato di implementare tutto da zero, avremmo fallito di sicuro. In retrospettiva, quasi ogni singolo requisito iniziale si dimostrò in seguito errato o incompleto, ma dato che eravamo pronti a imparare andando avanti, questo non fu un problema per noi.

Sono convinto che il segreto del nostro successo fu proprio il fatto di concentrarci sul dominio, e scrivere codice con una alta qualità interna, usando architettura esagonale e Test-Driven Development in modo quasi religioso fin dall’inizio. Alzare il livello della qualità del codice ci permise di ridurre i tempi complessivi, anche se potrebbe sembrare il contrario. Abbiamo ottimizzato il codice per il cambiamento, permettendoci il lusso di scoprire i requisiti man mano.

Isolare la logica dei sistemi esterni in un Anti-Corruption Layer permise di far procedere il lavoro sulla nuova logica in maniera indipendente da quello per adattarsi ai vari sistemi legacy con le loro idiosincrasie, spesso non documentate affatto.

Infine, l’esserci concentrati sul dominio ci permise di ridefinire la User Interface e la User Experience in maniera progressiva, senza venirne condizionati: infatti, è risultato più facile cambiarle dopo aver implementato i concetti fondamentali di un dominio in un’applicazione funzionante e robusta. Abbiamo visto altri team della stessa azienda commettere l’errore di focalizzarsi come prima cosa sull’usabilità, e ritrovarsi in grossa difficoltà nel momento in cui dovettero cambiarla, perché ormai faceva parte della loro architettura.
Nel nostro caso, anche se le nostre prime interfacce erano terribili, continuammo a migliorarle basandoci su feedback di utenti reali, invece di seguire esclusivamente le indicazioni degli esperti UX. Il risultato finale fu un’esperienza ottimale per gli utenti.

Conclusioni

EventStorming ci ha aiutato molto durante la definizione e l’inizio del progetto. Adottare le pratiche DDD anche con i “non-tecnici” ha aiutato tutti gli attori coinvolti nel progetto a raggiungere una comprensione comune, a condividere le priorità e a visualizzare i vari problemi inaspettati che emergevano man mano.

Anche se si presenta come un approccio molto tecnico, DDD per noi ha significato soprattutto aggregare le persone e condividere successi ed errori.

Se durante il meeting con gli stakeholder ti rendi conto che nessuno nella stanza è interessato al nuovo problema che sta emergendo, significa che hai dimenticato di invitare qualcuno.

Nel nostro progetto, grazie a DDD, siamo stati in grado di guadagnare la fiducia del resto dell’azienda nei confronti del reparto di sviluppo, e siamo anche stati in grado di dare fiducia al team offshore nel portare a termine progetti complessi in tempi brevi. Abbiamo rivisto continuamente il nostro processo, man mano che imparavamo, fino al punto in cui business e dev poterono lavorare fianco a fianco per implementare una nuova funzionalità in poche ore e vederla usare in produzione nello stesso giorno in cui fu richiesta.

Adottare DDD è stato cruciale per avere il supporto del top management per introdurre un nuovo modo di lavorare e convincere anche gli altri team a sperimentare questo approccio, influenzando la cultura aziendale generale.

Foto di Henry Be su Unsplash.

Cronache di Domain-Driven Design

Questa intervista è tratta dal libro Cronache di Domain-Driven Design, scritto da Alberto Acerbis, Matteo Baglini, Uberto Barbini, Alberto Brandolini, Alessandro Colla, Marco Consolaro, Emanuele DelBono, Gianluca Padovani e Francesco Strazzullo.
Il libro è disponibile su Leanpub in versione digitale e Amazon in versione cartacea.

DDD Open - Prossimi appuntamenti e segnalazioni

DDD Open è la community italiana dedicata a Domain-Driven Design. Uno spazio di discussione libero e partecipativo sul DDD aperto a esperti, neofiti, esploratori.
Abbiamo voluto creare uno spazio di discussione libero e partecipativo sul tema Domain-Driven Design aperto a esperti, neofiti, esploratori.

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.

Restiamo in contatto :)

Vuoi continuare a leggere le cose che pubblichiamo? Iscriviti alla nostra Newsletter 📩.
Ti faremo compagnia ogni venerdì mattina. ☕️

Julie Camosseto

Programme manager, executive and life coach. There is so much to gain by sharing mistakes made and lessons learned.

Uberto Barbini

JVM and Kotlin independent consultant. Passionate about Code Quality and Functional Programming. Author, public speaker and OpenSource contributor.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.