Peter Caron, CTO di Prima Assicurazioni, ci parla di Domain-Driven Design e Data Mesh, concetti che le imprese dovrebbero conoscere.
Negli ultimi vent’anni nel settore IT sono state introdotte numerose best practice per sviluppare rapidamente software di alta qualità; la conseguenza è che oggi i leader aziendali capiscono molto meglio cosa funziona e cosa non funziona. Purtroppo, molte organizzazioni non seguono i principi basilari delle buone pratiche di sviluppo. Soprattutto quando la crescita è rapida, i leader aziendali si lamentano dei lunghi tempi per lo sviluppo di nuove funzionalità, i team di prodotto non riescono a comprendere e gestire la complessità e i software engineer si ritrovano con dipendenze e duplicazioni di codice o dati.
Tra le numerose tecniche che migliorano la velocità e l’efficienza dello sviluppo software su ampia scala, due si distinguono nettamente dalle altre: Domain-Driven Design (DDD) e Data Mesh.
Il DDD scompone un dominio di business in una serie di contesti, chiamati bounded context, ciascuno con un linguaggio univoco o comune condiviso tra i software engineer , Product Manager e stakeholder , oltre a implementare confini fisici e logici chiaramente definiti. Il Data Mesh è l’implementazione dei principi del DDD e dei microservizi nei dati tramite la definizione di chiari confini fisici e logici all’interno di un contesto aziendale. Entrambi consentono lo sviluppo ad alte prestazioni nelle imprese che progettano software basati sul prodotto. In questo articolo, esaminerò i concetti di DDD e Data Mesh e andrò a proporre alcuni vantaggi pratici offerti dagli stessi , suggerendo il motivo per cui molte più aziende dovrebbero adottarli.
Domain-Driven Design
Il DDD è un approccio che ha il fine di allineare azienda e tecnologia a livello strutturale e organizzativo, ed è l’approccio standard per organizzare i team tecnologici in molte delle aziende di tecnologia di maggior successo. Nel DDD, un dominio (o sottodominio) è una raccolta di attività correlate con un vocabolario condiviso e confini distinti che lo separano da altri domini, che crea, fornisce e acquisisce valore. In altre parole, i domini aziendali sono divisi in insiemi di contesti inter correlati, coerenti o delimitati.
Il fine ultimo del DDD è quello di allineare l’architettura software, la strategia aziendale e la struttura organizzativa per ottenere una suite di prodotti o servizi organizzata in modo efficiente, scalabile e più facile da mantenere, separando chiaramente le problematiche. In questo paradigma, un dominio è l’area tematica in cui un servizio opera all’interno di un ambito limitato denominato “contesto delimitato” (o bounded context) che definisce i confini fisici e di responsabilità: ciò che è dentro, ciò che è fuori e ciò che si muove tra le due aree. Un singolo team ha la responsabilità per uno o più bounded contexts; ogni contesto è inserito in un dominio o sottodominio. All’interno di questo contesto delimitato, il team possiede i dati: ed è il DDD a consentire la responsabilità data-oriented, il primo principio del Data Mesh.
Data Mesh – Gestione e responsabilità dei dati
Il Data Mesh è un sistema di gestione decentralizzata dei dati che ne democratizza l’accesso e la condivisione per offrire “soluzioni analitiche e basate su ML qualitativamente elevate a livello di produzione”. Anziché organizzare i dati attorno alla tecnologia, il Data Mesh propone un’organizzazione in domini aziendali. L’architettura dei microservizi prevede che i servizi siano distribuibili in maniera indipendente. Ogni microservizio dovrebbe dunque essere responsabile di un singolo processo eseguibile. I dati sottostanti prodotti, archiviati e trasferiti dai microservizi, saranno “separati a livello logico ma non indipendenti” e suddivisi in base ai confini dei domini.
La gestione dei dati, uno dei fondamenti del Data Mesh, sostituisce un modello operativo di gestione centrale con un modello federato, che include i team decentralizzati. Il risultato è una maggiore responsabilità dei dati da parte dei team che li producono. È importante ricordare che l’obiettivo principale di qualsiasi architettura di microservizi è quello di isolare completamente, al maggior livello possibile, i servizi e i rispettivi dati.
In base alla logica, si potrebbe affermare che il Data Mesh sta ai dati come i domini stanno ai microservizi: la separazione è strutturata ma non indipendente e la creazione di compartimenti stagni viene scoraggiata. La separazione dei dati non ne implica l’isolamento: la flessibilità dei repository viene mantenuta dissociando le connessioni dirette tra i produttori e i consumatori a livello di dati; l’accesso dissociato alle fonti è sempre prioritario ma tali connessioni, anziché essere esposte, vengono gestite. Da un altro punto di vista, è possibile dichiarare che i dati vengono creati, modellati e mantenuti all’interno di un singolo dominio, anche se il valore effettivo si esprime nel momento in cui vengono pubblicati o condivisi all’esterno del relativo contesto delimitato.
Domini di dati e data product
I domini di dati rispecchiano da vicino i domini aziendali, svolgendo una funzione di business e offrendo dati analitici e operativi alle parti interessate. Possedendo e mantenendo la qualità dei propri dati, ogni dominio è responsabile di come pubblicarli e garantirne l’accessibilità agli altri. Applicare il product thinking ai dati orientati al dominio, “i dati come un prodotto” è il secondo principio del Data Mesh. Un data product incapsula tutti i componenti necessari per condividerli in modo aperto e sicuro oltre i confini. I dati analitici generati all’interno di un dominio rappresentano un buon esempio: il produttore tratta i dati come un prodotto e i consumatori come clienti di quel data product.
I product manager (o coloro che possiedono il prodotto) rimangono strettamente allineati e accoppiati ai domini. La persona addetta al product deve diventare, se non un esperto in materia, almeno in grado di articolare in dettaglio i requisiti degli stakeholder. Un product manager si allinea strettamente a un singolo sottodominio, mentre i team di software engineers sono solo vagamente accoppiati a un dominio. Ciononostante, in gran parte delle circostanze un team singolo lavora all’interno dei confini di un singolo dominio.
Il business dei dati
I modelli tradizionali di organizzazione dei dati si concentravano quasi esclusivamente sull’infrastruttura dei dati ed erano solitamente costruiti attorno a data lake o data warehouse gestiti a livello centrale. Esisteva un unico modello di dati canonico che chiunque utilizzasse il sistema doveva rispettare. Questi sistemi monolitici creavano dei colli di bottiglia nei team centrali, annullando la responsabilità dei produttori di dati.
Gli archivi di dati centralizzati procedono anche a una stretta associazione delle implementazioni di dati logici e fisici, limitando la capacità dei servizi di adattarsi in velocità. Distribuendo i dati attraverso i domini, i servizi possiedono e gestiscono i dati che producono. Al posto di un modello unico centrale e inflessibile che vada bene per tutti, il Data Mesh propone un modello di responsabilità di pubblicazione, servizio e condivisione: da un approccio di comando e controllo ad un processo decisionale autonomo. Idealmente, i dati vengono distribuiti e gestiti a livello locale o del sottodominio.
Il DDD e il Data Mesh realizzano entrambi gli obiettivi aziendali. La rete (mesh) è costituita da quei punti in cui i servizi si connettono con i consumatori dei loro dati come fili nella tela di un ragno. Il modo in cui queste interfacce vengono definite, prodotte e pubblicate costituisce gli elementi fondamentali di un data mesh e dei data product. Ancora una volta, i dati raggiungono il pieno potenziale quando diventano disponibili per il consumo da parte di un gruppo più ampio di servizi, prodotti, sviluppatori o analisti a livello interno.
Il Data Mesh non è un’architettura universale
Non tutti i dati dovrebbero essere distribuiti. I risultati possono giovare di un’architettura orientata al dominio se implementata correttamente e per le giuste ragioni. Quando sussiste una giustificazione aziendale convincente o definita per il passaggio al Data Mesh, i vantaggi di un modello di dati e servizi distribuiti produrranno benefici significativi, consentendo la creazione di preziosi data product a favore dell’intera organizzazione. La progettazione domain-driven e i concetti di data mesh contribuiscono alla riduzione dei tempi di consegna, consentendo agli stakeholder aziendali di essere molto più reattivi al cambiamento delle priorità rispetto a quanto si verificherebbe altrimenti.
Il DDD e il Data Mesh all’interno di Prima
Qualsiasi azienda che utilizza metodologie di sviluppo moderne insieme ai concetti di DDD e Data Mesh beneficerà di vantaggi potenzialmente significativi: costi inferiori, maggiore produttività e una superiore qualità del prodotto, con dipendenti generalmente più soddisfatti del lavoro che svolgono e con minori attriti rispetto alla media del settore. La sfida non verte su come sviluppare il software, bensì sul perché così poche aziende vi riescano bene, una tipologia di sfida che i senior leader dovrebbero considerare più da vicino. Il Domain-Driven Design e il Data Mesh sono concetti che le varie aziende caratterizzate da una mancanza di flessibilità, velocità e associazione, sia in software monolitici sia in sistemi di dati centralizzati, dovrebbero approfondire.
Questa visione, breve ed estremamente semplificata, dei concetti di Domain-Driven Design e Data Mesh propone due paradigmi per migliorare lo sviluppo del software e la gestione dei dati. Né il DDD né tanto meno il Data Mesh hanno delle regole fisse, offrendo al contrario dei framework pratici per sviluppare sistemi mantenibili ed estensibili finalizzati a sviluppare e mantenere il software con maggiore efficienza.
