Domini dati

La mesh dei dati, al centro, è fondata nella decentralizzazione e nella distribuzione della responsabilità nei domini. Se si comprende veramente questa parte dell'azienda, si è in grado di gestire i dati associati e di assicurarne l'accuratezza. Questo è il principio della proprietà dei dati orientata al dominio.

Per promuovere la proprietà dei dati orientata al dominio, è necessario innanzitutto creare una scomposizione dell'architettura dei dati. Il fondatore di data mesh Zhamak Dehghani promuove l'approccio DDD (Domain-Driven Design) allo sviluppo di 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. C'è anche spesso una mancanza di comprensione del DDD. I professionisti trovano le sue nozioni concettuali troppo difficili da comprendere o cercare di proiettare esempi di architettura software o 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.

Domain-Driven Design (Progettazione basata su domini)

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 per elementi come 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 è detta lingua 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 Operationalize data mesh for AI/ML (Rendere operativo la mesh di dati per intelligenza artificiale/Machine Learning).

Non tutti i sottodomini sono uguali. È ad esempio possibile 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 i prodotti fuori uso. I sottodomini di supporto non offrono vantaggi competitivi, ma sono necessari per mantenere un'organizzazione in esecuzione e in genere non sono complessi.

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

Consigli per la modellazione del dominio

Se si adotta una mesh di dati come concetto per la democratizzazione dei dati e si implementa il principio della proprietà dei dati orientata al 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 degli spazi di problema

Prima di consentire ai team di gestire i dati end-to-end, esaminare l'ambito e comprendere gli spazi di problema che si sta tentando 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.

Esaminare l'architettura aziendale quando si raggruppano gli spazi dei problemi. 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 osserverà in pratica è che la maggior parte delle persone è organizzata intorno alle funzionalità aziendali. Persone lavorare sulla stessa funzionalità aziendale 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.

Eseguire il mapping delle 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 le operazioni che l'organizzazione fa e hanno come destinazione gli spazi dei problemi. Quando si implementa una funzionalità aziendale, viene creata una realizzazione (istanza di funzionalità) per un contesto specifico. Più applicazioni e componenti interagiscono tra loro entro 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 affrontano 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 apprenderà nelle sezioni successive, la realtà a volte è diversa dall'ideale.

Se si esegue il mapping delle funzionalità a Tailwind Traders, i limiti del contesto delimitato e le implementazioni di dominio potrebbero essere simili al diagramma seguente.

In questo diagramma, la gestione dei clienti si basa su competenze in materia e quindi sa meglio quali dati servono ad altri domini. L'architettura interna della gestione dei clienti è disaccoppiata, quindi tutti i componenti dell'applicazione all'interno di questi limiti possono comunicare direttamente usando interfacce e modelli di dati specifici dell'applicazione.

I prodotti dati e gli standard di interoperabilità chiari vengono usati per formalizzare la distribuzione dei dati in 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 più realizzazione 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, la "gestione dei bagagli e gli articoli persi" è una funzionalità che viene soddisfatta per gli aerei correlati 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 diversi servizi tecnologici e team disgiunti per gestire tali servizi.

La relazione tra funzionalità e istanze di funzionalità (realizzazione) è 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. "Gestione clienti" 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 che 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 dati. Si potrebbe invece sostenere che esiste ancora una singola preoccupazione per i dati dal punto di vista delle funzionalità aziendali.

Per funzionalità condivise come pacchetti di fornitori complessi, soluzioni SaaS e sistemi legacy, essere coerenti nell'approccio di proprietà dei dati di dominio. È possibile separare la proprietà dei dati tramite i prodotti dati, che potrebbero richiedere miglioramenti dell'applicazione. Nell'esempio di "gestione dei clienti" di Tailwind Traders, pipeline diverse dal dominio applicazione possono generare più prodotti dati: un prodotto 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 applicazione di creare un singolo prodotto dati che incapsula i metadati per distinguere la proprietà dei dati all'interno di se stessa. È 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, ridistributi e allineati al consumer

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 di origine dorata. Leggere i prodotti dati ottimizzati dai domini per l'utilizzo intensivo dei dati. Facilitare questi domini usando servizi standardizzati per la trasformazione e la condivisione dei dati.

Questi servizi, che includono strutture di contenitori preconfigurati, 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 al consumer

I domini allineati al consumer sono l'opposto dei domini allineati all'origine. 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 rollforward

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à sia per i prodotti dati che per i casi d'uso analitici e ha progettato processi separati per la creazione di prodotti dati 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:

• È possibile usare un modello di modalità separato se si preferisce il costo associato della duplicazione rispetto alla riutilizzabilità. La riutilizzabilità viene sacrificata per una maggiore flessibilità e agilità.
• Un modello fornitore cliente può essere usato se un dominio è forte e disposto a assumere la proprietà dei dati e delle esigenze dei consumatori downstream. Gli svantaggi includono problemi in conflitto e forzare i team downstream a negoziare risultati finali e pianificare 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 con e considerano le esigenze degli altri. Poiché nessuno può cambiare liberamente la logica condivisa, è necessario un impegno significativo da parte di tutti.
• Un modello conforme può essere usato per conformare tutti i domini a tutti i requisiti. Usare questo modello quando il lavoro di integrazione è complesso, nessun'altra parte può avere il controllo o usare pacchetti 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 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 del cliente di dati
• Miglioramento della qualità dei dati, inclusa l'adesione ai contratti di servizio e alle misure di qualità impostate dai consumer 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 verifiche di accesso IAM e la creazione del contratto dati

Livello di granularità per il disaccoppiamento

Ora si sa come riconoscere e facilitare i domini dati, è possibile imparare a progettare il livello corretto di granularità e regole del dominio per la separazione. 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. Cercare di separare ogni volta che i dati superano i limiti delle funzionalità 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 delle 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 dei domini. 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 orientato all'origine e ai limiti orientati ai consumatori. La metà dei team di dominio potrebbe avere un valore per determinati servizi rispetto ad 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, esaminare la scomposizione del dominio e determinare quali domini funzionali sono candidati per la condivisione dell'infrastruttura sottostante.

Riepilogo

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 stato di destinazione mappando tutto in anticipo è un esercizio intensivo. Suggeriscono invece di identificare i domini in modo organico durante l'onboarding nella nuova architettura della mesh di dati. Invece di definire lo stato di destinazione dall'alto verso il basso, si lavora in basso, esplorando, sperimentando e passando lo stato corrente verso uno stato di destinazione. Anche se questo approccio proposto potrebbe essere più rapido, comporta un rischio significativo. È possibile essere facilmente al centro di un'operazione di spostamento o rimodellazione complessa quando le operazioni iniziano a interrompersi. Lavorare da entrambe le direzioni, dall'alto verso il basso e dal basso verso l'alto, e quindi incontrare in mezzo nel tempo è un approccio più sfumato.

Passaggio successivo

• Che cos'è un prodotto dati?