DDD nel mondo dei Dati

DataMesh

DDD nel mondo dei Dati

Ma come? Ho sempre detto che DDD ha nei suoi principi base il modo di affrontare il problema partendo dalle esigenze del business, ed ora mi ritrovo a scrivere che DDD si occupa di come raccogliere dati?

Parlando di architetture moderne uno dei pattern strategici chiave del DDD, il Bounded Context, è da sempre legato al concetto di microservizio. Bounded Context, Context Mapping e Ubiquitous Language sono i pattern chiave per suddividere la soluzione in aree ben definite, con contratti di comunicazione chiari ed espliciti. Questo per quanto riguarda l’impatto del DDD nel così detto mondo del backend.

Negli ultimi anni, non contenti di aver suddiviso il monolite lato backend, ci siamo inventati i microfrontend, un modo per suddividere il frontend in tanti Bounded Context, ed ecco nuovamente i pattern strategici del DDD venirci a supportare, per far fronte al crescere della complessità lato frontend nelle moderne soluzioni software.

La pace dei sensi per noi sviluppatori sembrava raggiunta, ora la catena di gestione del problema lato business sembrava completa, partendo da un microfrontend, che fa riferimento a servizi REST esposti dal relativo microservizio, fino ad arrivare alla totale e completa padronanza del database sottostante, sia che si tratti di un servizio CRUD o di un servizo con pattern CQRS/ES.

Ma in tutto questo come si colloca la raccolta dei dati? E prima ancora, c’è differenza fra i dati raccolti nei database dei singoli microservizi, che chiameremo Dati Operativi, e quelli raccolti nei DataLake, ossia i database destinati a raccogliere i dati per scopi statistici a supporto di modelli di ML, che chiameremo Dati Analitici?

Dati Operativi

Sono i dati salvati nei database dei microservizi delle nostre applicazioni ed hanno la responsabilità di mantenere lo stato corrente del business. Sono dati fondamentali per le scelte continue che gli utilizzatori dei nostri software devono continuamente fare. Particolare molto importante, anzi fondamentale, è il fatto che questi dati sono assolutamente privati, quindi non accessibili da altri servizi. E’ il microservizio che li gestisce che decide cosa, e come, condividerli con il mondo esterno.

Dati Analitici

È la visione storica, integrata e aggregata dei dati creati come prodotto secondario della gestione aziendale. Viene mantenuta e utilizzata dai sistemi OLAP (online analytical processing).
I dati analitici sono la visione temporale, storica e spesso aggregata dei fatti dell’azienda nel tempo. Vengono modellati per fornire informazioni retrospettive o future.
I dati analitici sono ottimizzati per la logica analitica, l’addestramento di modelli di apprendimento automatico e la creazione di report e visualizzazioni all’esterno”, ovvero i dati a cui accedono direttamente i consumatori analitici.

Data Mesh

In tutto questo, DDD che ruolo ha? Data Mesh, direttamente dall’autrice Zhamak Dehghani, è un approccio sociotecnico decentralizzato per condividere, accedere e gestire i dati analitici in ambienti complessi e su larga scala, all’interno o tra le organizzazioni.

Rispetto agli approcci precedenti nella gestione dei dati analitici, Data Mesh introduce alcuni cambiamenti che la figura seguente, tratta dall’omonimo libro, riassume brillantemente

Data Mesh – Dimensioni del cambiamento

I Principi Fondamentali

Visto dall’esterno Data Mesh sembra un ritorno ai silos di dati; il fatto di suddividere la raccolta dei dati per Dominio potrebbe far pensare ad un ritorno al passato, ma Zhamak Dehghani, che per prima ha proposto questo approccio, ha definito quattro principi fondamentali che evitano, tra gli altri, anche questo pericolo.

Questi principi sono pensati per aumentate il valore dei dati, sostenere l’agilità durante la crescita aziendale e abbracciare il cambiamento in un contesto aziendale volatile e complesso.

Ma quali sono questi principi?

  • Principio della proprietà del Dominio
  • Principio dei dati come prodotto
  • Principio della piattaforma dati self-service
  • Principio della governance computazionale

Per poter comprendere a fondo cosa cambia veramente rispetto ad un approccio tradizionale è utile comprendere che in Data Mesh si parla più di pubblicazione, che non di importazione, dei dati, poichè è più importante individuare e utilizzare i dati piuttosto che estrarli e caricarli su qualche Data Lake.

Vediamo un pò più nel dettaglio le proprietà di ogni singolo principio

Principle of Domain Ownership

Ispirandosi al concetto di Dominio espresso in DDD i dati vengono organizzati in Domini; in senso stretto un Dominio comprende una serie di dati omogenei rispetto ad alcuni criteri che possono essere l’origine, l’aggregazione ed il consumo degli stessi. In questo approccio ci sono diversi aspetti che possiamo definire rivoluzionari rispetto al modo tradizionale di raccolta dati. Innanzitutto il processo di gestione dei dati viene posto sotto la ownership di un team interdisciplinare di attori tutti operanti nella sfera di competenza di questi dati, ed ancora si nota l’influenza di DDD in questo principio rimarcando l’importanza dei Business Expert per poter comprendere e sfruttare pienamente le potenzialità.

Questa differenziazione rispetto ad un modello a Data Lake, che vede il convogliamento di tutti i dati operativi in unico ambiente, riduce l’entropia informativa derivante dal fatto che le figure che presidiano il Data lake stesso non possono essere esperte di tutti i domini interessati.

Le motivazioni che supportano questo principio sono diverse

  • La capacità di scalare la condivisione dei dati allineata con gli assi della crescita organizzativa: aumento del numero delle fonti di dati, aumento del numero dei consumatori di questi stessi dati e aumento della diversità dei casi d’uso di consumo degli stessi.
  • Ottimizzazione del cambiamento continuo grazie alla localizzazione del cambiamento nei domini aziendali
  • Supporto all’agilità riducendo la necessità di sincronizzazione tra i team rimuovendo i colli di bottiglia nell’avere un team centralizzato per la raccolta dati che faccia riferimento ad un unico Data Lake
  • Aumentare la resilienza delle soluzioni di machine learning rimuovendo complesse pipeline di raccolta dati intermedie

Il rischio che si corre scomponendo i dati per dominio è quello di creare dei silos, rischiando di compromettere l’integrazione e la coerenza complessiva. Ma per evitare questo ci sono altri principi da seguire.

Principle of Data as a Product

Un pò come il Context Mapping risolve il rapporto di comunicazione fra i vari Bounded Context il Principio di Dati come Prodotto indica la modalità con cui i singoli domini interagiscono per garantire una gestione fluida ed efficiente dei processi aziendali. Abbiamo già detto che Data Mesh è orientato a gestire dati analitici, ossia dati che derivano da aggregazioni e/o integrazioni, ma va anche precisato che questi dati possono avere finalità differenti, ad esempio, rendicontazione interna tramite dashboard e/o report, analisi e ricerca, magari sfruttando modelli di Machine Learning, o persino supporto a processi operativi a valle degli stessi che li hanno generati.

Per Data Product si intende una collezione di dati, corredata dal codice necessario al relativo consumo, e dei metadati che ne descrivono contenuto, accuratezza, età, fonti, ownership, modalità di consumo, insomma delle relative caratteristiche. E’ realizzato all’interno del Dominio dei Dati, ed è destinato sia al consumo interno dal Dominio stesso, ma anche al consumo da parti degli altri Domini, grazie ad catalogo centrale che censisce tutti i data product e assicura l’adeguata interoperabilità fra i Domini.

Per poter garantire tutto questo, un Data Product deve rispondere ad un set minimo di otto criteri, per cui deve essere

  • Ricercabile
  • Indirizzabile
  • Comprensibile
  • Affidabile
  • Accessibile
  • Interoperabile
  • di Valore
  • Sicuro

Principle of the Self-Service Data Platform

L’applicazione del solo principio di Dominio dei Dati, lo abbiamo detto, porta al rischio della generazione di silos isolati. Il rischio è mitigato dal secondo principio che abbiamo esplorato, che favorisce l’interoperabilità fra i domini stessi. Il principio di Self-Service Data Platform porta a una nuova generazione di servizi di piattaforma di dati che consentono ai team interfunzionali di dominio di condividere i dati stessi. I servizi che troviamo in questa piattaforma sono proprio incentrati sull’eliminazione degli attriti che ci possono essere nel percorso end-to-end della condivisione dei dati, dal producer al consumer. Questi servizi gestiscono una rete affidabile di Product Data interconnessi, come la visualizzazione sia in forma lineare, sia in forma di grafi. Fra gli scopi di questa tipologia di piattaforme vi è proprio la semplificazione dell’esperienza utente nello scoprire, accedere e utilizzare i Data Product. Le motivazioni a supporto di questo principio sono

  • Ridurre il costo totale della proprietà decentralizzata dei dati
  • Astrarre la complessità della gestione dei dati e ridurre il carico cognitivo dei team di dominio nella gestione del ciclo di vita dei Data Product
  • Mobilitare una generazione di sviluppatori più generalista della tecnologia per lo sviluppo di Data Product, riducendo la necessità di specializzazione
  • Automatizzare le politiche di governance per creare standard di sicurezza e di conformità per tutti i Data Product

Principle of Federated Computational Governance

Lo scopo è quello di evitare a tutti i costi il proliferare di silos di dati. Questo principio porta proprio alla creazione di un modello operativo di governance dei dati basato su una struttura decisionale e di responsabilità federata, grazie ad un team composto da rappresentanti del dominio, della piattaforma dati e da business expert. Il modello operativo crea una struttura di incentivi e responsabilità che bilancia l’autonomia e l’agilità dei domini con l’interoperabilità globale della rete e sull’automazione delle politiche di gestione per ogni Data Product.

I motivi alla base di questo principio sono

  • La capacità di ottenere un valore di ordine superiore dall’aggregazione e dalla correlazione di prodotti di dati indipendenti, ma interoperabili
  • Contrastare le conseguenze indesiderate della decentralizzazioni orientate al dominio, quali incompatibilità e disconnesione dei domini
  • Rendere possibile l’inserimento di requisiti di governance trasversali, come la sicurezza, la privacy, la conformità legale, etc, in una rete di Data Product distribuita.
  • Ridurre l’overhead della sincronizzazione manuale tra i domini e la funzione di governance

L’interazione dei principi

L’idea di base di Zhamak Dehghani è quella che i quattro principi siano colletivamente necessari e sufficienti. In effetti si completano a vicenda, e ognuno affronta e risolve le sfide generate dagli altri. La figura seguente mostra l’interazione fra di essi

Conclusioni

Sicuramente ho solo scalfito il problema, e sicuramente tornerò a parlarne. DDD mi affascina da sempre, sono certo che non ho ancora appreso tutto ciò che ha da insegnare, e la dimostrazione è proprio questo approccio alla gestione dei dati sfruttando proprio i pattern del DDD stesso.

Consiglio vivamente, a chi fosse interessato ad approfondire l’argomento, la lettura del libro dell’autrice di Data Mesh Zhamak Dehghani che trovate qui.

Al solito, restate connessi.

Did you like this post?

Condividi questo post...

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *