Domini dati

Il data mesh si basa fondamentalmente sulla decentralizzazione e sulla distribuzione della responsabilità ai domini. Se si comprende veramente una parte dell'azienda, si è in grado di gestire i dati associati e di garantirne l'accuratezza. Questo è il principio della proprietà dei dati orientata al dominio.

Per promuovere la proprietà dei dati orientata al dominio, è necessario innanzitutto scomporre l'architettura dei dati. Il fondatore di data mesh, Zhamak Dehghani, promuove l'approccio Domain-Driven Design (DDD) allo sviluppo software come metodo utile per identificare i domini dati.

La difficoltà con l'uso di DDD per la gestione dei dati è che il caso d'uso originale di DDD era la modellazione di sistemi complessi in un contesto di sviluppo software. Non è stato originariamente creato per modellare i dati aziendali e per i professionisti della gestione dei dati, il metodo può essere astratto e tecnico. Spesso vi è una mancanza di comprensione del DDD. I professionisti trovano le sue nozioni concettuali troppo difficili da comprendere o cercare di proiettare esempi dall'architettura software o dalla programmazione orientata agli oggetti nel loro panorama dei dati. Questo articolo fornisce indicazioni pragmatici e un vocabolario chiaro, in modo da poter comprendere e usare DDD.

Progettazione basata su dominio

Introdotto da Eric Evans, Domain-Driven Design è un metodo per supportare lo sviluppo di software che consente di descrivere sistemi complessi per organizzazioni di grandi dimensioni. DDD è popolare perché molte delle procedure di alto livello influisce sugli approcci moderni di sviluppo di software e applicazioni, ad esempio i microservizi.

DDD distingue tra contesti, domini e sottodomini delimitati. I domini sono spazi problematici da risolvere. Sono aree in cui le conoscenze, il comportamento, le leggi e le attività si riuniscono. Viene visualizzato l'accoppiamento semantico nei domini, le dipendenze comportamentali tra componenti o servizi. Un altro aspetto dei domini è la comunicazione. I membri del team devono usare una lingua che l'intero team condivide in modo che tutti possano lavorare in modo efficiente. Questa lingua condivisa viene chiamata linguaggio comune o lingua di dominio.

I domini vengono scomposti in sottodomini per gestire meglio la complessità. Un esempio comune è la scomposizione di un dominio in sottodomini che corrispondono a un problema aziendale specifico, come illustrato in Rendere operativa la mesh di dati per intelligenza artificiale/apprendimento automatico.

Non tutti i sottodomini sono uguali. È possibile, ad esempio, classificare i domini come core, generici o di supporto. I sottodomini principali sono i più importanti. Sono la salsa segreta, gli ingredienti, che rendono unica un'organizzazione. I sottodomini generici non sono specifici e in genere sono facili da risolvere con prodotti pronti all'uso. I sottodomini di supporto non offrono un vantaggio competitivo, ma sono necessari per mantenere un'organizzazione operativa e non sono complessi.

I contesti delimitati sono limiti di contesto logici. Si concentrano sullo spazio della soluzione: la progettazione di sistemi e applicazioni. Si tratta di un'area in cui l'allineamento dell'attenzione sullo spazio delle soluzioni ha senso. All'interno di DDD questo può includere codice, progettazioni di database e così via. Tra i domini e i contesti delimitati è possibile eseguire l'allineamento, ma non esiste alcuna regola rigida che associa i due elementi. I contesti delimitati sono tecnici per natura e possono estendersi su più domini e sottodomini.

Consigli per la modellazione del dominio

Se si adotta il data mesh come concetto di democratizzazione dei dati e si implementa il principio della proprietà dei dati a livello di dominio per aumentare la flessibilità, come funziona in pratica? Quale potrebbe essere la transizione dalla modellazione dei dati aziendali alla modellazione della progettazione basata su dominio? Quali lezioni è possibile trarre da DDD per la gestione dei dati?

Creare una scomposizione funzionale delle aree problematiche

Prima di consentire ai vostri team di gestire i loro dati end-to-end, esaminate l'ambito e comprendete gli ambiti problematici che state cercando di risolvere. È importante eseguire questo esercizio prima di passare ai dettagli di un'implementazione tecnica. Quando si impostano limiti logici tra questi spazi di problema, le responsabilità diventano più chiare e possono essere gestite meglio.

Esamina l'architettura aziendale quando raggruppi le aree problematiche. All'interno dell'architettura aziendale sono disponibili funzionalità aziendali: capacità o capacità che un'azienda possiede o scambia per ottenere uno scopo o un risultato specifico. Questa astrazione include dati, processi, organizzazioni e tecnologie in un contesto specifico, in linea con gli obiettivi e gli obiettivi aziendali strategici dell'organizzazione. Una mappa delle funzionalità aziendali mostra quali aree funzionali sembrano essere necessarie per soddisfare la tua missione e la tua visione.

È possibile visualizzare la scomposizione delle funzionalità di una società fittizia, Tailwind Traders, nel modello seguente.

Tailwind Traders deve gestire tutte le aree funzionali elencate nella mappa delle funzionalità aziendali per avere esito positivo. Tailwind Traders deve essere in grado di vendere biglietti come parte dei sistemi di gestione dei ticket online o offline, ad esempio, o avere i piloti disponibili per volare come parte di un programma di gestione pilota. L'azienda può esternalizzare alcune attività mantenendone altre come il nucleo della sua attività.

Ciò che si osserva in pratica è che la maggior parte delle persone è organizzata intorno alle funzionalità aziendali. Le persone che lavorano sulle stesse funzionalità aziendali condividono lo stesso vocabolario. Lo stesso vale per le applicazioni e i processi, che in genere sono ben allineati e strettamente connessi in base alla coesione delle attività supportate.

Il mapping delle funzionalità aziendali è un ottimo punto di partenza, ma la tua storia non termina qui.

Associare le funzionalità aziendali alle applicazioni e ai dati

Per gestire meglio l'architettura aziendale, allineare le funzionalità aziendali, i contesti delimitati e le applicazioni. È importante seguire alcune regole di base mentre lo fai.

Le funzionalità aziendali devono rimanere al livello aziendale e rimanere astratte. Rappresentano ciò che fa la tua organizzazione e indirizzano i tuoi spazi problematici. Quando si implementa una funzionalità aziendale, viene creata una realizzazione (istanza di funzionalità) per un contesto specifico. Più applicazioni e componenti interagiscono all'interno di tali limiti nello spazio della soluzione per offrire valore aziendale specifico.

Le applicazioni e i componenti allineati a una particolare funzionalità aziendale rimangono separati dalle applicazioni allineate ad altre funzionalità aziendali, in quanto rispondono a problemi aziendali diversi. I contesti delimitati derivano da e vengono mappati esclusivamente alle funzionalità aziendali. Rappresentano il limite di un'implementazione delle funzionalità aziendali e si comportano come un dominio.

Se le funzionalità aziendali cambiano, i contesti delimitati cambiano. È preferibile prevedere l'allineamento completo tra domini e contesti delimitati corrispondenti, ma come si apprende nelle sezioni successive, la realtà a volte è diversa dall'ideale.

Se si esegue la mappatura delle funzionalità a Tailwind Traders, i limiti del contesto delimitato e le implementazioni di dominio potrebbero essere simili al diagramma che segue.

In questo diagramma, la Gestione clienti si basa sull'expertise specifica e quindi è in grado di determinare quali dati servire agli altri domini. L'architettura interna di Customer Management è disaccoppiata, quindi tutti i componenti dell'applicazione all'interno di questi limiti possono comunicare direttamente usando interfacce e modelli di dati specifici dell'applicazione.

prodotti di dati e standard chiari di interoperabilità vengono usati per formalizzare la distribuzione di dati ad altri domini. In questo approccio, tutti i prodotti dati sono allineati al dominio e ereditano il linguaggio comune, che è un linguaggio costruito e formalizzato concordato dagli stakeholder e dai progettisti dello stesso dominio, per soddisfare le esigenze di tale dominio.

Domini aggiuntivi da molteplici realizzazioni di funzionalità

È importante riconoscere quando si lavora con le mappe delle funzionalità aziendali che alcune funzionalità aziendali possono essere create più volte.

Ad esempio, Tailwind Traders potrebbe avere più realizzazione localizzate (o implementazioni) di "gestione dei bagagli e oggetti persi". Si supponga che una linea di attività opera solo in Asia. In questo contesto, "gestione dei bagagli e articoli smarriti" è una capacità offerta per gli aeroplani relativi all'Asia. Un'altra linea d'affari potrebbe puntare al mercato europeo, e in questo contesto viene usata un'altra funzionalità di "gestione dei bagagli e articoli persi". Questo scenario di più istanze può portare a più implementazioni localizzate usando servizi tecnologici diversi e team non contigui per gestire tali servizi.

La relazione tra capacità aziendale e istanze di capacità (realizzazioni) è uno-a-molti. Per questo motivo, si finisce con domini aggiuntivi (secondari).

Trovare funzionalità condivise ed esaminare i dati condivisi

È importante gestire le funzionalità aziendali condivise. Le funzionalità condivise vengono in genere implementate centralmente, come modelli di servizio, e fornite a diverse linee di business. "Customer Management" può essere un esempio di questo tipo di funzionalità. Nell'esempio di Tailwind Traders, sia le linee di business asiatiche che europee usano la stessa amministrazione per i propri clienti.

Ma come è possibile proiettare la proprietà dei dati di dominio in una funzionalità condivisa? Più rappresentanti aziendali prendono probabilmente la responsabilità per i clienti all'interno della stessa amministrazione condivisa.

È presente un dominio applicazione e un dominio dati. Il dominio e il contesto delimitato non sono perfettamente allineati dal punto di vista del prodotto di dati. Si potrebbe invece sostenere che esiste ancora un singolo problema di dati dal punto di vista delle capacità aziendali.

Per funzionalità condivise come pacchetti di fornitori complessi, soluzioni SaaS e sistemi legacy, siate coerenti nel vostro approccio alla gestione della proprietà dei dati di dominio. È possibile separare la proprietà dei dati attraverso i prodotti dati, che potrebbero richiedere miglioramenti alle applicazioni. Nell'esempio "Customer Management" di Tailwind Traders, pipeline diverse provenienti dal dominio dell'applicazione possono generare più prodotti di dati: un prodotto di dati per tutti i clienti correlati all'Asia e uno per tutti i clienti correlati all'Europa. In questo caso, più domini dati provengono dallo stesso dominio applicazione.

È anche possibile chiedere ai domini applicativi di creare un singolo prodotto dati che incapsuli i metadati per distinguere al suo interno la proprietà dei dati. È possibile, ad esempio, riservare un nome di colonna per la proprietà, mappando ogni riga a un singolo dominio dati specifico.

Identificare i monoliti che offrono più funzionalità aziendali

Prestare attenzione anche alle applicazioni che soddisfano più funzionalità aziendali, spesso viste in aziende di grandi dimensioni e tradizionali. In questo scenario di esempio Tailwind Traders usa un pacchetto software complesso per facilitare la "gestione dei costi" e "asset e finanziamenti". Queste applicazioni condivise sono monoliti che forniscono il maggior numero possibile di funzionalità, rendendole grandi e complesse. In una situazione di questo tipo, il dominio dell'applicazione deve essere più grande. Lo stesso vale per la proprietà condivisa, in cui diversi domini dati risiedono in un dominio applicazione.

Modelli di progettazione per domini allineati all'origine, riconsegnati e allineati al consumatore

Quando si esegue il mapping dei domini, è possibile scegliere un modello in base alla creazione, al consumo o alla ridistribuzione dei dati. Per l'architettura, è possibile progettare modelli che supportano i domini in base alle caratteristiche specifiche del dominio.

Domini allineati al sistema di origine

I domini allineati al sistema di origine sono allineati ai sistemi di origine in cui hanno origine i dati. Questi sistemi sono in genere transazionali o operativi.

L'obiettivo è quello di acquisire i dati direttamente da questi sistemi sorgente principali. Prodotti di dati ottimizzati per la lettura dai vostri domini fornitori per il consumo intensivo di dati. Facilitare questi domini usando servizi standardizzati per la trasformazione e la condivisione dei dati.

Questi servizi, che includono strutture di contenitori preconfigurate, consentono ai team di dominio orientati all'origine di pubblicare più facilmente i dati. È il percorso della minima resistenza con interruzioni minime e costi.

Domini allineati ai consumatori

I domini allineati al consumatore sono l'opposto dei domini allineati alla sorgente. Sono allineati a casi d'uso specifici dell'utente finale che richiedono dati da altri domini. I domini allineati al cliente usano e trasformano i dati in base ai casi d'uso dell'organizzazione.

Valutare la possibilità di offrire servizi dati condivisi per la trasformazione e il consumo dei dati per soddisfare queste esigenze di utilizzo. È possibile offrire funzionalità di infrastruttura dati indipendenti dal dominio, ad esempio, per gestire pipeline di dati, infrastruttura di archiviazione, servizi di streaming, elaborazione analitica e così via.

Domini di ridistribuzione

La riutilizzabilità dei dati è uno scenario diverso e più difficile. Ad esempio, se i consumer downstream sono interessati a una combinazione di dati di domini diversi, è possibile creare prodotti dati che aggregano dati o combinare dati di alto livello richiesti da molti domini. In questo modo è possibile evitare il lavoro ripetitivo.

Non creare dipendenze complesse tra i prodotti dati e i casi d'uso analitici. Cercare invece flessibilità e accoppiamento libero. Il modello seguente illustra come ottenere flessibilità. Un dominio acquisisce la proprietà dei prodotti di dati e dei casi d'uso analitici e ha progettato processi separati per la creazione e l'utilizzo dei dati.

Definire modelli di dominio sovrapposti

La modellazione del dominio spesso diventa complicata quando i dati o la logica di business vengono condivisi tra domini. Nelle organizzazioni su larga scala, i domini spesso si basano sui dati di altri domini. Può essere utile avere domini generici che forniscono logica di integrazione in modo da consentire ad altri sottodomini di standardizzare e trarre vantaggio da esso. Mantenere il modello condiviso tra sottodomini di piccole dimensioni e sempre allineato al linguaggio comune.

Per i requisiti di dati sovrapposti, è possibile usare modelli diversi dalla progettazione basata su dominio. Ecco un breve riepilogo dei modelli tra cui scegliere:

• Un schema a percorsi separati può essere utilizzato se si preferisce sostenere i costi associati alla duplicazione rispetto alla riutilizzabilità. La riutilizzabilità viene sacrificata per una maggiore flessibilità e agilità.
• Un modello di fornitore del cliente può essere usato se un dominio è forte e disposto a acquisire la proprietà dei dati e delle esigenze dei consumatori downstream. Gli svantaggi includono preoccupazioni in conflitto e costringere i team downstream a negoziare le consegne e accordare le priorità.
• Un modello di partnership può essere usato quando la logica di integrazione è coordinata in modo non pianificato all'interno di un dominio appena creato. Tutti i team collaborano tra loro e considerano le esigenze degli altri. Poiché nessuno può cambiare liberamente la logica condivisa, è necessario un impegno significativo da parte di tutti.
• Un modello conformista può essere usato per conformare tutti i tuoi domini a tutti i requisiti. Usare questo modello quando il lavoro di integrazione è complesso, nessun'altra parte deve avere il controllo o si usano pacchetti del fornitore.

In tutti i casi, i domini devono rispettare gli standard di interoperabilità. Un dominio di partnership che produce nuovi dati per altri domini deve esporre i propri prodotti dati come qualsiasi altro dominio, incluso l'acquisizione della proprietà.

Responsabilità del dominio

La mesh di dati decentralizza la proprietà dei dati distribuendola tra i team di dominio. Per molte organizzazioni, questo significa un passaggio da un modello centralizzato intorno alla governance a un modello federato. Ai team di dominio vengono assegnate attività, ad esempio:

• Acquisizione della proprietà delle pipeline di dati, ad esempio inserimento, pulizia e trasformazione dei dati, per soddisfare il maggior numero possibile di esigenze dei clienti di dati
• Miglioramento della qualità dei dati , inclusa l'adesione agli accordi sui livelli di servizio e alle misure di controllo della qualità impostate dai fruitori di dati
• Incapsulare i metadati o usare nomi di colonna riservati per il filtro a livello di riga e colonna con granularità fine
• Aderendo agli standard di gestione dei metadati, tra cui:
  • Registrazione dello schema dell'applicazione e del sistema di origine
  • Metadati per migliorare l'individuabilità
  • Informazioni sul controllo delle versioni
  • Collegamento di attributi di dati e termini aziendali
  • Integrità delle informazioni sui metadati per consentire una migliore integrazione tra domini
• Conformità agli standard di interoperabilità dei dati, inclusi protocolli, formati di dati e tipi di dati
• Fornire la derivazione collegando i sistemi di origine e i servizi di integrazione agli scanner o fornendo manualmente la derivazione
• Aderendo alle attività di condivisione dei dati, incluse le revisioni di accesso IAM e la creazione del contratto sui dati

Livello di granularità per il disaccoppiamento

Ora che sai come riconoscere e facilitare i domini di dati, puoi imparare a progettare il livello corretto di granularità dei domini e le regole per il disaccoppiamento. Due dimensioni importanti sono in gioco quando si scompone l'architettura.

La granularità per i domini funzionali e l'impostazione di contesti delimitati è una dimensione. I domini sono conformi a un particolare modo di funzionare, assicurandosi che i dati diventino disponibili per tutti i domini che usano servizi condivisi, prendendo la proprietà, rispettando gli standard dei metadati e così via.

Impostare limiti con granularità fine, se possibile per la distribuzione dei dati. Diventare basati sui dati consiste nel rendere i dati disponibili per il riutilizzo intensivo. Se si rendono troppo liberi i limiti, si forzano gli accoppiamenti indesiderati tra molte applicazioni e si perde la riutilizzabilità dei dati. Impegnarsi per il disaccoppiamento ogni volta che i dati attraversano i confini delle capacità aziendali. All'interno di un dominio è consentito un accoppiamento stretto all'interno dell'architettura interna del dominio. Tuttavia, quando si superano i limiti delle funzionalità aziendali, i domini devono rimanere separati e distribuire prodotti dati ottimizzati per la lettura per la condivisione con altri domini.

La granularità per i domini tecnici e l'utilizzo dell'infrastruttura è l'altra dimensione importante. Le zone di destinazione dei dati consentono l'agilità per la manutenzione applicazioni dati, che creano prodotti dati. Come si crea questo tipo di zona di destinazione con l'infrastruttura condivisa e i servizi sottostanti? I domini funzionali sono raggruppati logicamente e sono buoni candidati per la condivisione dell'infrastruttura della piattaforma. Ecco alcuni fattori da considerare durante la creazione di queste zone di destinazione:

• La coesione e l'efficienza quando si lavora e si condividono i dati è un forte fattore di allineamento dei domini funzionali a una zona di destinazione dei dati. Ciò si riferisce alla gravità dei dati, la tendenza a condividere costantemente prodotti di dati di grandi dimensioni tra domini.
• I limiti a livello di area possono comportare l'implementazione di zone di destinazione dei dati aggiuntive.
• La proprietà, la sicurezza o i limiti legali possono forzare la separazione del dominio. Ad esempio, alcuni dati non possono essere visibili ad altri domini.
• La flessibilità e il ritmo del cambiamento sono fattori importanti. Alcuni domini possono avere una velocità elevata di innovazione, mentre altri domini hanno una forte stabilità dei valori.
• I limiti funzionali possono separare i team. Un esempio di questo potrebbe essere i confini orientati alle fonti e ai consumatori. Metà dei team di dominio potrebbe valutare alcuni servizi più di altri.
• Se si vuole potenzialmente vendere o separare la funzionalità, è consigliabile evitare di integrare strettamente i servizi condivisi da altri domini.
• Le dimensioni, le competenze e la maturità del team possono essere fattori importanti. I team altamente qualificati e maturi spesso preferiscono gestire i propri servizi e le proprie infrastrutture, mentre i team meno maturi hanno meno probabilità di dare un valore al sovraccarico aggiuntivo della manutenzione della piattaforma.

Prima di effettuare il provisioning di molte zone di destinazione dei dati, esaminate la decomposizione del vostro dominio e determinate quali domini funzionali sono candidati per la condivisione dell'infrastruttura sottostante.

Sommario

La modellazione delle funzionalità aziendali consente di riconoscere e organizzare meglio i domini in un'architettura mesh di dati. Offre una visione olistica del modo in cui i dati e le applicazioni offrono valore all'azienda, consentendo allo stesso tempo di classificare in ordine di priorità e concentrarsi sulla strategia dei dati e sulle esigenze aziendali. È anche possibile usare la modellazione delle funzionalità aziendali per più di semplici dati. Ad esempio, se la scalabilità è un problema, è possibile usare questo modello per identificare le funzionalità principali più critiche e sviluppare una strategia per loro.

Alcuni professionisti sollevano la preoccupazione che la creazione di un'architettura di destinazione mappando tutto in anticipo sia un esercizio intensivo. Suggeriscono invece di identificare organicamente i domini mentre li integri nella tua nuova architettura dati a maglia. Invece di definire lo stato di destinazione dall'alto verso il basso, si lavora dal basso verso l'alto, esplorando, sperimentando e trasformando lo stato attuale verso uno stato di destinazione. Anche se questo approccio proposto potrebbe essere più rapido, comporta un rischio significativo. Ti ritrovi facilmente nel bel mezzo di un'operazione di spostamento o ristrutturazione complessa quando le cose iniziano a rompersi. Lavorare da entrambe le direzioni, dall'alto verso il basso e dal basso verso l'alto, e quindi unirsi gradualmente nel tempo è un approccio più raffinato.

Passaggio successivo

• Che cos'è un prodotto di dati?