GESTIRE LA COMPLESSITÀ DEL SOFTWARE

Transcript

1 UNIVERSITÀ DEGLI STUDI DI URBINO CARLO BO Dipartimento di Scienze di Base e Fondamenti Scuola di Scienze e Tecnologie dell Informazione Tesi di Laurea GESTIRE LA COMPLESSITÀ DEL SOFTWARE CON DOMAIN DRIVEN DESIGN E CQRS Relatore: Chiar.mo Prof. Edoardo Bontà Candidato: Stefano Ottaviani Corso di Laurea in Informatica Applicata Anno Accademico

2 ii Alla mia famiglia, a Dany e a Palli

3 Indice 1 Introduzione Elogio alla community Contesto Organizzazione Domain Driven Design L essenza di DDD Esploriamo il nostro dominio Make the implicit explicit Il Domain Model Il Domain Model anemico Il vero Domain Model Il costo di DDD (e CQRS) L approccio da usare in base al contesto L Esperto di Dominio (Domain Expert) L Ubiquitous Language Quale lingua usare nel codice? L Ubiquitous Language ed il refactoring Pattern tattici e strategici Domini e Bounded Context Core Domain, Subdomains, I Bounded Context I Bounded Context e la duplicazione Context Mapping Modellazione con DDD Le Entità (Entity) I Value Object L immutabilità dei Value Object Entità o Value Object? Value Object e DTO Attenzione ai Value Object nei contratti Gli Aggregati (Aggregate) iii

4 3.3.1 Gli aggregati come unità di consistenza Gli aggregati e le invarianti Le invarianti e le bozze (draft) I Servizi di Dominio (Domain Service) Gli Eventi di Dominio (Domain Events) Long-Running Process: Process Manager e Saga Esempi di modellazione Considerazioni generali sulla modellazione Separazione dello stato dall aggregato Il pattern Draft - Contract (a.k.a. Collaborative Construction) Eliminazione delle entità Validazioni ed eccezioni Repository e Query Objects Task Based UI Domain Driven Security DDD brutto, sporco e cattivo CQRS Breve introduzione a CQRS Da CQS a CQRS Task Based UI Event Sourcing Eventual Consistency Messaggistica asincrona tramite Service Bus Non è tutto oro Problematiche con i Service Bus Problematiche con gli Event Store Problemi con Eventual Consistency Problematiche con il refactoring Ricchezza di informazioni negli eventi Query sul dominio e validazione dei comandi Notifica degli errori ai client I prossimi step Event Storming e Model Storming Un po di storia I problemi con la modellazione tradizionale La modellazione collaborativa con Event Storming Approfondimenti Alcune esperienze di applicazione Case Study su CQRS 65 iv

5 7 Case Study: intranet aziendale by Proximo Srl L esigenza Prima analisi e prototipo Uso di Event Storming e Model Storming Il sistema realizzato Il sistema documentale (DMS) Il sistema per la gestione delle prenotazioni delle risorse Architettura del sistema La scelta di DDD e CQRS+ES The big picture Il write model Il read model Indicizzazione dei documenti con Lucene ed Elasticsearch Modellazione del dominio Uso dell Ubiquitous Language Modellazione del DMS Uso dei Process Manager Value Object e sicurezza Ricchezza di informazioni negli eventi del dominio Informazioni sul contesto di esecuzione delle operazioni Implementazione Tipizzazione degli Id degli aggregati Separazione dello stato dell aggregato Verifica delle invarianti degli aggregati Validazioni Salvataggio dei comandi Integrazione con Active Directory Replay degli eventi di dominio Eliminazione delle informazioni Test del sistema Prossimi sviluppi Conclusioni Case Study: S.I.C.O. by SID Srl L esigenza Il prototipo Il dominio Architettura Eventi di Dominio e di Sistema Due modelli per Eventi e Comandi Flusso di Elaborazione dei Comandi Il read model Informazioni sul contesto di esecuzione delle operazioni Il client web v

6 8.4.7 Aggiornamento della UI SignalR al posto di WebApi Versione degli aggregati in caso di split degli eventi Privacy delle informazioni Reportistica Conclusioni Conclusioni 113 A Codice sorgente 114 A.1 Codice dal case study: intranet by Proximo Srl A.1.1 Esecuzione dei comandi con retry A.1.2 Classe base per il read model A.1.3 Chiamate asincrone dal client, con supporto del timeout 117 A.1.4 Esempio di test tramite MSpec A.2 Codice dal case study: S.I.C.O. by SID Srl A.2.1 Dispatcher dei comandi dal bus ai CommandHandler A.2.2 Classe base per la realizzazione di un CommandHandler 126 A.2.3 Classe base per la realizzazione delle projection sul Read Model A.3 Codice di esempio A.3.1 Process Manager: handler degli eventi A.3.2 Process Manager Bibliografia 137 Ringraziamenti 144 vi

7 Elenco delle figure 1.1 Pattern e definizioni di DDD (fig. tratta da [15]) Il diverso valore delle varie parti Modellazione di un dominio con Event Storming Modellatori all opera durante il corso di Brandolini Disposizione degli eventi di dominio Disposizione dei comandi Identificazione degli aggregati Esempio della variante usata da Proximo Applicazione di Model Storming Caricamento di un file nell area documentale Documento in attesa di essere analizzato Documento analizzato e pronto per la pubblicazione Notifica esito dell operazione asincrona di pubblicazione Comando accodato in attesa di essere eseguito Gestione dei documenti pubblicati nella bacheca Gestione scheda informativa del documento Statistiche di visualizzazione - riepilogo Statistiche di visualizzazione - dettaglio utenti Ricerca documenti con facets, scoring e full text Scheda informativa del documento Richiesta di prenotazione risorsa - Step Richiesta di prenotazione risorsa - Step Richiesta di prenotazione risorsa - Step Pannello autorizzativo delle richieste di prenotazione Home page con notifiche su prenotazioni Architettura della intranet Tracciabilità degli eventi Visita ambulatoriale, composta da molti aggregati Esempio di anagrafica Interazione tra i sottosistemi Flusso di Elaborazione Comandi vii

8 8.6 Esempio di stampa a video Esempio di stampa generata con JasperReports viii

9 Elenco delle tabelle ix

10 Capitolo 1 Introduzione 1.1 Elogio alla community Nel momento in cui dovevo scegliere l argomento per questo lavoro, mi sarebbe piaciuto trattare due temi: la gestione della complessità con Domain Driven Design e l uso di mezzi social che possano aiutare nell attività di sviluppo delle applicazioni. In particolare, mi sarebbe piaciuto affrontare l argomento delle community di sviluppatori e della loro organizzazione, attività a cui mi dedico da anni. Nell immaginario collettivo, la nostra professione è associata a quella dello smanettone che scrive codice come un forsennato, rinchiuso nel suo scantinato ed isolato dal resto del mondo. Ma se manca il confronto con gli altri sviluppatori, probabilmente è una delle migliori ricette per ottenere del codice pessimo: magari funzionante, ma privo delle qualità che un buon codice dovrebbe avere. Ho avuto la fortuna di entrare in contatto con il mondo delle community di sviluppatori circa una decina di anni fa: prima tramite i newsgroup ed i forum, poi tramite community come UgiDotNet, infine gestendo direttamente un paio di user group a livello regionale, DotNetMarche e XPUG Marche. Con sicurezza posso affermare che, oltre alla formazione scolastica, gli user group sono stati lo strumento che maggiormente mi hanno permesso di imparare sia come scrivere software in modo nettamente migliore, sia come affrontare le altre componenti relative alla gestione di un prodotto o di un progetto. Ciò è stato possibile grazie al dialogo e al confronto con persone intelligenti e disponibili a scambiare gratuitamente le proprie idee, opinioni ed esperienze, col coraggio di riportare anche quelle fallimentari, invece di chiudersi nel proprio orticello cercando di nascondere i propri segreti. Questo è lo scambio culturale che porta ad un effettiva crescita e a cui tutti coloro che svolgono la nostra professione farebbero bene a partecipare e contribuire. Alla fine ho optato per la gestione della complessità come argomento per

11 1.2 Contesto 2 questa tesi, ma ho deciso al contempo di contribuire maggiormente alla community di sviluppatori, cercando in particolare di ravvivare quella del territorio in cui vivo. Per questo, insieme ad altre persone, abbiamo deciso di impegnarci per dar vita proprio in questi giorni ad un iniziativa che abbiamo chiamato DevMarche, il network delle community marchigiane che si occupano di sviluppo software. Mi sono sentito di fare questo elogio alle community, oltre che per invitare a parteciparvi chi ancora non conoscesse questo mondo, soprattutto perché la maggior parte del mio percorso di formazione su Domain Driven Design è avvenuta proprio grazie ad esse, ad iniziare dalla conoscenza stessa di questo argomento. Senza il contributo delle persone con cui negli anni abbiamo organizzato workshop e scambiato molte idee su questi temi, questo lavoro non sarebbe stato sicuramente possibile, perciò un riconoscimento è d obbligo! 1.2 Contesto Il progresso tecnologico dovuto alla presenza di computer sempre più veloci e capaci, e di strumenti più evoluti per sviluppare software, è stato accompagnato dalla richiesta da parte del mercato di creare applicazioni che risolvessero esigenze sempre più complesse. Purtroppo, però, le maggiori risorse degli elaboratori, o i sofisticatissimi ambienti di sviluppo che abbiamo oggi a disposizione, da soli non sono in grado di gestire tali esigenze. La complessità 1 può essere dovuta a diversi fattori, giusto per citarne qualcuno: - La necessità di creare sistemi in cui più applicazioni, possibilmente sviluppate da team o aziende diverse, collaborino tra loro. Ad esempio, il sistema di e-commerce ed il gestionale che vogliono sapere disponibilità e movimenti della merce dal sistema logistico, il quale a sua volta riceve da essi informazioni sulle merci da spedire. - Dover creare sistemi che possano servire da pochi utenti fino a centinaia di migliaia o milioni, possibilmente scalando in modo intelligente in base ai picchi delle richieste e garantendo tempi di risposta rapidi, per un pubblico sempre più esigente ed abituato a ciò che i grandi player riescono ad offrire (es. le ricerche rapidissime di Google). - La necessità di avere sistemi capaci di gestire molte logiche di business e di adattarsi in modo rapido alle evoluzioni del mercato, magari dovendo supportare al contempo scenari tra loro piuttosto diversi. - Dover sviluppare sistemi in contesti in cui non esiste un vero esperto di dominio autoritario e la conoscenza del funzionamento del sistema deve essere estrapolata cercando di sfruttare il più possibile tutte le fonti di informazioni disponibili. 1 N.B.: complesso è diverso da complicato

12 1.2 Contesto 3 - I sistemi attuali debbono poter essere usufruibili dai device più disparati: l era del desktop sta lasciando il posto a quella dell accesso alle informazioni in mobilità e a quella dell internet delle cose. Durante la mia esperienza lavorativa ho sviluppato soprattutto software per l ambito gestionale e della logistica di magazzino, sviluppando tra le altre cose dei WMS (Warehouse Management System) usufruibili sia da desktop che da dispositivi mobile. Sicuramente alcuni di questi sistemi possono essere catalogati come complessi : anche se non era richiesto il requisito dell alta scalabilità, dovendo servire al massimo centinaia di utenti per installazione, ci ritrovavamo in situazioni con molte regole di business e workflow che cambiavano radicalmente da cliente a cliente. Dovevamo integrarci di continuo con altre applicazioni, sia di sistemi completamente esterni, sia facenti parti del nostro stesso pacchetto. Ad esempio, sono capitate situazioni in cui ci trovavamo a lavorare in 5-6 aziende per realizzare diverse componenti di un unico sistema logistico: chi sviluppava la parte delle spedizioni, chi quella degli ingressi della merce e così via. Tutte queste parti del software dovevano comunicare tra loro e con sistemi esterni, come l ERP del cliente o il sito di e-commerce. In altre situazioni dovevamo gestire la spedizione di merci di diverse tipologie, che dovevano essere sincronizzate per essere spedite su uno stesso camion: potevano diventare disponibili in fasi diverse della giornata, arrivando in tempo reale sia dalla produzione interna, sia da fornitori esterni, oppure essendo già stoccate in magazzino. Ovviamente il tutto doveva essere reso più automatico e trasparente possibile per gli operatori di magazzino, quando non avevamo poi direttamente un magazzino automatico, con i vari robottini a cui comunicare le operazioni da fare per gestire la merce. Fortunatamente i progetti sono stati consegnati funzionanti, ma il codice ottenuto diciamo che rifletteva molto la complessità del dominio: sicuramente i tempi e gli sforzi necessari per scriverlo non sono stati indifferenti e spesso, purtroppo, di gran lunga superiori alle previsioni. Le difficoltà incontrate durante lo sviluppo non sono state poche. Tra queste, abbiamo avuto problemi di manutenibilità nel riuscire a gestire sempre nuove logiche di business, facendole convivere con le altre esistenti. Ci sono state difficoltà di varia natura nell integrazione tra le diverse componenti, relative sia alle modalità di scambio di informazioni tra esse, sia al riuscire ad avere una sorta di transazionalità distribuita. Spesso abbiamo dovuto gestire la scrittura di query che diventavano piuttosto complesse, mettendo in relazione tra di loro troppe tabelle, o il dover fornire a posteriori informazioni per l auditing del sistema, non previsto originariamente. In diverse occasioni, poi, non avevamo a disposizione un vero esperto di dominio che conosce la situazione del cliente, perciò occorreva ricavare in qualche modo le informazioni che ci servivano. La ricerca di soluzioni che potessero aiutarmi a governare questa complessità, che potrei definire sia tecnica che di gestione del progetto, è passata

13 1.2 Contesto 4 attraverso vari argomenti: tra questi, la strutturazione di applicazioni secondo vari pattern architetturali come le Layered Architecture, MVC, e affini, o l uso di principi come i SOLID [1], la Dependecy Injection e l Inversion of Control. Ma gli argomenti che probabilmente hanno dato maggiori soluzioni a riguardo sono state le metodologie agili e Domain Driven Design, due temi che tra l altro si integrano bene tra loro. Domain Driven Design (DDD) non è un argomento nuovo: Eric Evans lo presentò nel 2003 tramite il libro Domain-Driven Design: Tackling Complexity in the Heart of Software [2], chiamato familiarmente il blue book. Già il suo titolo è esplicativo sulla volontà di gestire la complessità intrinseca dei software. Personalmente, la prima occasione in cui ne ho sentito parlare è stata nel 2007, grazie al workshop [4]. Purtroppo nei primi anni dall introduzione di DDD, c è stato un certo fraintendimento che probabilmente ne ha frenato un po la diffusione. Sia a causa della strutturazione del blue book, sia probabilmente del fatto che il suo target principale è stato quello degli sviluppatori, la componente di DDD che nei primi anni ha avuto più risalto è stata quella tecnica, a discapito di quella strategica maggiormente legata ad argomenti di business. In quegli anni si parlava spesso di temi quali l organizzazione delle applicazioni tramite un Domain Model da usare in combinazione con un ORM; oppure, di altri aspetti tecnici come quelli relativi alla gestione dei repository per l accesso ai dati, o alla strutturazione delle classi all interno del codice in entità, value object ed aggregati. Altri temi della parte strategica, come i Bounded Context e le Context Map, non venivano spesso trattati. Fortunatamente negli ultimi anni sono accadute diverse cose che hanno contribuito a cambiare radicalmente lo scenario. Eric Evans stesso ha tenuto, nel 2009, la sessione What I ve learned about DDD since the book [5] in cui ha spostato decisamente il focus su alcuni argomenti che nel libro erano stati lasciati in fondo e quasi ignorati: oltre ai già citati Bounded Context e Context Map, ha ribadito il significato e l importanza della modellazione del dominio e dell utilizzo dell Ubiquitous Language. Inoltre, ha presentato nuovi concetti emersi in quegli anni, come l utilizzo dei Domain Events. Anche altre persone hanno contribuito: tra questi c è sicuramente Alberto Brandolini, che, oltre ad aver dato vita alla community italiana su DDD [8], ha offerto molti spunti relativi soprattutto alla parte strategica, durante innumerevoli workshop ed incontri in cui è stato possibile confrontarsi con lui. Altre due persone, Greg Young e Udi Dahan, intorno al 2008 hanno iniziato a formulare e diffondere CQRS (Command Query Responsibility Segregation), un tema strettamente legato a DDD (tanto che inizialmente si parlava di Distributed DDD) che fornisce ulteriori strumenti, molto potenti, per la gestione della complessità. Dagli ultimi 2-3 anni, ci troviamo in uno scenario completamente cambiato: DDD e CQRS sono diventati due argomenti decisamente hot, tra quelli

14 1.3 Organizzazione 5 più trattati da chi si occupa di ingegnerizzare e architettare software, a prescindere dalla piattaforma tecnologica. A riprova di ciò, giusto per citare un esempio anche il team Pattern & Practice di Microsoft ha scritto una guida per esplorare questi temi [9]. Tutto questo fermento è accompagnato però ancora da una certa immaturità nel saper gestire questi argomenti, complice anche il fatto che si tratta di andare a lavorare in scenari complessi. Le scelte migliori da adottare molto spesso dipendono dal contesto specifico in cui si va ad operare e non possono essere analizzate partendo da soluzioni generiche. Occorre fare molta esperienza, perché altrimenti si rischia facilmente, soprattutto parlando di CQRS, di adottare delle soluzioni tecniche che possono portare a complicarsi ulteriormente la vita invece di semplificarsela. O, peggio ancora, a delle soluzioni che possono avere gravi problemi di cui ci si potrebbe accorgere solo una volta andati in produzione o nel momento in cui occorre fare aggiornamenti al sistema. Anche perché, come dice Greg Young [10], è importante considerare che ciò che appare semplice in un contesto a scala ridotta può essere molto complesso su grande scala e viceversa! 1.3 Organizzazione Questo viaggio esplorativo attraverso Domain Driven Design (DDD) e CQRS non vuole essere un introduzione a tali argomenti, sia perché non ci sarebbe lo spazio materiale per farlo, sia perché già esistono molte risorse più adeguate a riguardo. Basta dare uno sguardo alla figura 1.1 per rendersi conto di quanti pattern e definizioni entrano in gioco già parlando solamente di DDD! Immagino che comunque alcuni dei lettori di questo lavoro potrebbero non avere alcuna conoscenza di DDD e CQRS: nel testo cercherò di riportare delle brevi introduzioni agli argomenti trattati, ma potrebbero non essere sufficienti per una piena comprensione. In tal caso, oltre alla consultazione delle risorse già citate, consiglio la visione di altre fonti: alcune sintetiche sono [15] per quanto riguarda DDD e [12] e [13] per CQRS. Per approfondimenti, oltre al già citato blue book, sono disponibili diverse risorse, tra cui il libro Implementing Domain-Driven Design [3] che tratta sia DDD che CQRS, ed una serie di video di oltre 6 ore di Greg Young su CQRS [14]. Piuttosto, questo lavoro vuole essere un excursus attraverso alcuni aspetti su cui vorrei porre particolare enfasi, perciò il target più indicato è chi ha avuto già un infarinatura su DDD e CQRS e vuole approfondire l argomento. Nel caso di DDD, molte delle argomentazioni ho avuto la possibilità di sperimentarle in pratica, quindi avendo a disposizione dei riscontri in prima persona. Invece, nel caso di CQRS non ho purtroppo avuto modo di fare altrettanta pratica diretta. Vista però l importanza di esperienza con sistemi andati effettivamente in produzione, per i motivi indicati precedentemente nella

15 1.3 Organizzazione 6 Figura 1.1: Pattern e definizioni di DDD (fig. tratta da [15]) sez. 1.2, ho voluto cercare qualcosa di analogo, individuandolo nella possibilità offertami da due persone, Andrea Balducci e Alessandro Giorgetti, di realizzare dei case study su dei progetti che hanno realizzato in quest ultimo paio di anni. Tra l altro con Andrea e Alessandro abbiamo avuto la possibilità di condividere parte del percorso di formazione tramite una serie di workshop e conferenze a cui abbiamo partecipato o che abbiamo organizzato insieme, come il DDD-Day [11]. Il materiale riportato sarà quindi frutto di esperienze dirette, di discussioni con altre persone, di partecipazioni a corsi, workshop e conferenze, ed in molti casi di letture e confronti attraverso canali quali forum, blog e twitter, che troppo spesso sono dei mezzi un po dispersivi delle conoscenze, ma attraverso i quali a volte passano informazioni molto importanti. In particolare, per quanto riguarda corsi e workshop, tra i più importanti a cui ho partecipato