Datadomäner

Data mesh bygger i grunden på decentralisering och ansvarsfördelning till domäner. Om du verkligen förstår den här delen av verksamheten är du bäst positionerad för att hantera associerade data och säkerställa dess noggrannhet. Det här är principen om domänorienterat dataägarskap.

För att främja domänorienterat dataägarskap måste du först göra en nedbrytning av din dataarkitektur. Data mesh-grundaren Zhamak Dehghani främjar DDD-metoden (Domain-Driven Design) för programvaruutveckling som en användbar metod som hjälper dig att identifiera dina datadomäner.

Svårigheten med att använda DDD för datahantering är att DDD:s ursprungliga användningsfall var modellering av komplexa system i en programvaruutvecklingskontext. Den skapades inte ursprungligen för att modellera företagsdata, och för datahanteringsutövare kan dess metod vara abstrakt och teknisk. Det finns också ofta en brist på förståelse för DDD. Utövare tycker att dess konceptuella begrepp är för svåra att förstå, eller försöker projicera exempel från programvaruarkitektur eller objektorienterad programmering till deras datalandskap. Den här artikeln ger dig pragmatisk vägledning och tydlig vokabulär så att du kan förstå och använda DDD.

Domändriven design

Domändriven design introducerades av Eric Evans och är en metod för att stödja programvaruutveckling som hjälper till att beskriva komplexa system för större organisationer. DDD är populärt eftersom många av dess metoder på hög nivå påverkar moderna program- och programutvecklingsmetoder för saker som mikrotjänster.

DDD skiljer mellan avgränsade kontexter, domäner och underdomäner. Domäner är problemutrymmen som du vill åtgärda. Det är områden där kunskap, beteende, lagar och aktiviteter samlas. Du ser semantisk koppling i domäner, beteendeberoenden mellan komponenter eller tjänster. En annan aspekt av domäner är kommunikation. Teammedlemmar måste använda ett språk som hela teamet delar så att alla kan arbeta effektivt. Det här delade språket kallas för det allestädes närvarande språket eller domänspråket.

Domäner delas upp i underdomäner för att bättre hantera komplexitet. Ett vanligt exempel på detta är att dela upp en domän i underdomäner som var och en motsvarar ett specifikt affärsproblem, vilket visas i Operationalize data mesh for AI/ML.

Alla underdomäner är inte desamma. Du kan till exempel klassificera domäner som antingen grundläggande, generiska eller stödjande. Kärnunderdomäner är de viktigaste. Det är den hemliga såsen, ingredienserna, som gör en organisation unik. Generiska underdomäner är ospecificerade och är vanligtvis enkla att lösa med produkter som inte finns på hyllan. Stödunderdomäner erbjuder inte konkurrensfördelar, men är nödvändiga för att hålla en organisation igång och är vanligtvis inte komplex.

Avgränsade kontexter är logiska (kontext)-gränser. De fokuserar på lösningsutrymmet: utformningen av system och program. Det är ett område där fokus på lösningsutrymmet är meningsfullt. I DDD kan detta omfatta kod, databasdesign och så vidare. Mellan domänerna och avgränsade kontexter kan det finnas justering, det finns ingen hård regel som binder ihop de två. Avgränsade kontexter är tekniska till sin natur och kan omfatta flera domäner och underdomäner.

Rekommendationer för domänmodellering

Om du använder datanät som ett begrepp för datademokratisering och implementerar principen om domänorienterat dataägarskap för att öka flexibiliteten, hur fungerar detta i praktiken? Hur kan en övergång från företagsdatamodellering till domändriven designmodellering se ut? Vilka lärdomar kan du ta från DDD för datahantering?

Göra en funktionell affärsuppdelning av dina problemutrymmen

Innan du låter dina team använda sina data från slutpunkt till slutpunkt bör du titta på omfånget och förstå de problemutrymmen som du försöker åtgärda. Det är viktigt att göra den här övningen först innan du går in på detaljerna i en teknisk implementering. När du anger logiska gränser mellan dessa problemutrymmen blir ansvarsområdena tydligare och kan hanteras bättre.

Titta på din affärsarkitektur när du grupperar dina problemutrymmen. Inom affärsarkitekturen finns det affärsfunktioner: förmågor eller kapaciteter som ett företag har eller utbyter för att uppnå ett specifikt syfte eller resultat. Den här abstraktionen packar data, processer, organisation och teknik i en viss kontext, i enlighet med organisationens strategiska affärsmål och mål. En karta över affärskapacitet visar vilka funktionella områden som verkar vara nödvändiga för att uppfylla ditt uppdrag och din vision.

Du kan visa funktionsfördelning för ett fiktivt företag, Tailwind Traders, i följande modell.

Tailwind Traders måste hantera alla funktionella områden som anges i affärskapacitetskartan för att lyckas. Tailwind Traders måste till exempel kunna sälja biljetter som en del av Online- eller Offline Tickets Management Systems, eller ha piloter tillgängliga för att flyga flygplan som en del av ett pilothanteringsprogram. Företaget kan outsourca vissa aktiviteter och samtidigt behålla andra som kärnan i sin verksamhet.

Vad du kommer att se i praktiken är att de flesta av dina medarbetare är organiserade kring affärsfunktioner. Personer som arbetar med samma affärskapacitet delar samma ordförråd. Detsamma gäller för dina program och processer, som vanligtvis är välanpassade och nära anslutna baserat på sammanhållningen i de aktiviteter som de stöder.

Mappning av affärskapacitet är en bra utgångspunkt, men din berättelse slutar inte här.

Mappa affärsfunktioner till program och data

Om du vill hantera företagsarkitekturen bättre justerar du dina affärsfunktioner, begränsade kontexter och program. Det är viktigt att följa vissa grundregler när du gör det.

Affärsfunktionerna måste ligga kvar på affärsnivå och förbli abstrakta. De representerar vad din organisation gör och riktar in sig på dina problemutrymmen. När du implementerar en affärsfunktion skapas en realisering (kapacitetsinstans) för en specifik kontext. Flera program och komponenter fungerar tillsammans Inom sådana gränser i ditt lösningsutrymme för att leverera specifika affärsvärden.

Program och komponenter som är anpassade till en viss affärskapacitet förblir frikopplade från program som är anpassade till andra affärsfunktioner, eftersom de hanterar olika affärsproblem. Avgränsade kontexter härleds från och mappas exklusivt till affärsfunktioner. De representerar gränsen för en implementering av affärskapacitet och de beter sig som en domän.

Om affärsfunktionerna ändras ändras begränsade kontexter. Du kan helst förvänta dig fullständig justering mellan domäner och motsvarande avgränsade kontexter, men som du lär dig i senare avsnitt skiljer sig verkligheten ibland från idealet.

Om vi projicerar kapacitetsmappning till Tailwind Traders kan begränsade kontextgränser och domänimplementeringar se ut ungefär som i följande diagram.

I det här diagrammet bygger kundhantering på ämnesexpertis och vet därför bäst vilka data som ska användas till andra domäner. Kundhanteringens inre arkitektur är frikopplad, så alla programkomponenter inom dessa gränser kan kommunicera direkt med hjälp av programspecifika gränssnitt och datamodeller.

Dataprodukter och tydliga interoperabilitetsstandarder används för att formalisera datadistribution till andra domäner. I den här metoden överensstämmer alla dataprodukter också med domänen och ärver det allestädes närvarande språket, som är ett konstruerat, formaliserat språk som intressenter och designers kommit överens om från samma domän, för att tillgodose domänens behov.

Extra domäner från flera funktionsförverkan

Det är viktigt att känna till att vissa affärsfunktioner kan instansieras flera gånger när du arbetar med affärskapacitetskartor.

Tailwind Traders kan till exempel ha flera lokaliserade genomföranden (eller implementeringar) av "bagagehantering och förlorade föremål". Anta att en rad av deras verksamhet endast fungerar i Asien. I detta sammanhang är "bagagehantering och förlorade föremål" en funktion som uppfylls för Asien-relaterade flygplan. Ett annat affärsföretag kan rikta in sig på den europeiska marknaden, och i detta sammanhang används en annan "bagagehantering och förlorade föremål"-kapacitet. Det här scenariot med flera instanser kan leda till flera lokaliserade implementeringar med hjälp av olika tekniktjänster och olika team för att driva dessa tjänster.

Relationen mellan affärskapacitet och kapacitetsinstanser (genomföranden) är en-till-många. På grund av detta får du extra domäner (underdomäner).

Hitta delade funktioner och se upp för delade data

Hur du hanterar delade affärsfunktioner är viktigt. Du implementerar vanligtvis delade funktioner centralt, som tjänstmodeller, och tillhandahåller dem till olika affärslinjer. "Kundhantering" kan vara ett exempel på den här typen av funktioner. I vårt Tailwind Traders-exempel använder både de asiatiska och europeiska verksamhetslinjerna samma administration för sina kunder.

Men hur kan du projicera domändataägarskap på en delad funktion? Flera företagsrepresentanter tar sannolikt ansvar för kunder som inom samma delade administration.

Det finns en programdomän och en datadomän. Din domän och avgränsade kontext justeras inte helt från en dataproduktsynpunkt. Du kan omvänt hävda att det fortfarande finns ett enda dataproblem ur affärskapacitetssynpunkt.

För delade funktioner som komplexa leverantörspaket, SaaS-lösningar och äldre system ska du vara konsekvent i din domändataägarmetod. Du kan separera dataägarskapet via dataprodukter, vilket kan kräva programförbättringar. I vårt Exempel på kundhantering i Tailwind Traders kan olika pipelines från programdomänen generera flera dataprodukter: en dataprodukt för alla Asien-relaterade kunder och en för alla Europa-relaterade kunder. I det här fallet kommer flera datadomäner från samma programdomän.

Du kan också be dina programdomäner att skapa en enda dataprodukt som kapslar in metadata för att särskilja dataägarskap inom sig själv. Du kan till exempel reservera ett kolumnnamn för ägarskap och mappa varje rad till en enda specifik datadomän.

Identifiera monoliter som erbjuder flera affärsfunktioner

Var också uppmärksam på program som tillgodoser flera affärsfunktioner, som ofta ses i stora och traditionella företag. I vårt exempelscenario använder Tailwind Traders ett komplext programvarupaket för att underlätta både "kostnadshantering" och "tillgångar och finansiering". Dessa delade program är monoliter som ger så många funktioner som möjligt, vilket gör dem stora och komplexa. I sådana fall bör programdomänen vara större. Samma sak gäller för delat ägande, där flera datadomäner finns i en programdomän.

Designmönster för källjusterade domäner, omleverans och konsumentjusterade domäner

När du mappar dina domäner kan du välja ett mönster baserat på skapande, förbrukning eller omleverans av dina data. För din arkitektur kan du utforma mallar som stöder dina domäner baserat på domänens specifika egenskaper.

Källsystemjusterade domäner

Källsystemjusterade domäner är anpassade till källsystem där data kommer. Dessa system är vanligtvis transaktionella eller operativa.

Målet är att samla in data direkt från dessa gyllene källsystem. Läsoptimera dataprodukter från dina domäner för intensiv dataförbrukning. Underlätta dessa domäner med hjälp av standardiserade tjänster för datatransformering och delning.

Dessa tjänster, som omfattar förkonfigurerade containerstrukturer, gör det enklare för dina källorienterade domänteam att publicera data. Det är vägen till minsta motstånd med minimala störningar och kostnader.

Konsumentjusterade domäner

Konsumentjusterade domäner är motsatsen till källjusterade domäner. De är anpassade till specifika användningsfall för slutanvändare som kräver data från andra domäner. Kundjusterade domäner använder och transformerar data för att passa din organisations användningsfall.

Överväg att erbjuda delade datatjänster för datatransformering och förbrukning för att tillgodose dessa konsumtionsbehov. Du kan erbjuda domänoberoende datainfrastrukturfunktioner, till exempel för att hantera datapipelines, lagringsinfrastruktur, streamingtjänster, analysbearbetning och så vidare.

Omleverera domäner

Återanvändning av data är ett annat och svårare scenario. Om nedströmskonsumenter till exempel är intresserade av en kombination av data från olika domäner kan du skapa dataprodukter som aggregerar data eller kombinera data på hög nivå som krävs av många domäner. På så sätt kan du undvika repetitivt arbete.

Skapa inte starka beroenden mellan dina dataprodukter och analysanvändningsfall. Sträva efter flexibilitet och lös koppling istället. Följande modell visar hur du kan uppnå flexibilitet. En domän äger både dataprodukter och analytiska användningsfall och har utformat separata processer för skapande av dataprodukter och dataanvändning.

Definiera överlappande domänmönster

Domänmodellering blir ofta komplicerat när data eller affärslogik delas mellan domäner. I storskaliga organisationer förlitar sig domäner ofta på data från andra domäner. Det kan vara bra att ha generiska domäner som tillhandahåller integreringslogik på ett sätt som gör att andra underdomäner kan standardisera och dra nytta av den. Håll din delade modell mellan underdomäner liten och alltid i linje med det allestädes närvarande språket.

För överlappande datakrav kan du använda olika mönster från domändriven design. Här är en kort sammanfattning av de mönster du kan välja mellan:

• Ett separat sätt mönster kan användas om du föredrar den associerade kostnaden för duplicering framför återanvändning. Återanvändning offras för högre flexibilitet och flexibilitet.
• Ett mönster för kund-leverantör kan användas om en domän är stark och villig att ta ansvar för nedströmskonsumenternas data och behov. Nackdelarna är motstridiga problem och tvingar dina underordnade team att förhandla om slutprodukt- och schemaprioriteringar.
• Ett partnerskapsmönster kan användas när din integreringslogik samordnas på ett oplanerat sätt inom en nyskapad domän. Alla team samarbetar med och tar hänsyn till varandras behov. Eftersom ingen fritt kan ändra den delade logiken krävs betydande engagemang från alla inblandade.
• Ett konformistiskt mönster kan användas för att anpassa alla dina domäner till alla krav. Använd det här mönstret när ditt integreringsarbete är komplext, inga andra parter kan ha kontroll eller om du använder leverantörspaket.

I samtliga fall bör dina domäner följa dina interoperabilitetsstandarder. En partnerskapsdomän som producerar nya data för andra domäner måste exponera sina dataprodukter som alla andra domäner, inklusive ägarskap.

Domänansvar

Data mesh decentraliserar dataägarskapet genom att distribuera dem mellan domänteam. För många organisationer innebär detta en övergång från en centraliserad modell kring styrning till en federerad modell. Domänteam tilldelas uppgifter, till exempel:

• Ägarskapet för datapipelines, till exempel inmatning, rensning och transformering av data, för att hantera så många datakunders behov som möjligt
• Förbättra datakvaliteten, inklusive efterlevnad av serviceavtal och kvalitetsmått som anges av datakonsumenter
• Kapsla in metadata eller använda reserverade kolumnnamn för detaljerad filtrering på rad- och kolumnnivå
• Följer standarder för metadatahantering, inklusive:
  • Registrering av program- och källsystemschema
  • Metadata för förbättrad identifiering
  • Versionsinformation
  • Länkning av dataattribut och affärsvillkor
  • Integritet för metadatainformation för bättre integrering mellan domäner
• Följa standarder för datakompatibilitet, inklusive protokoll, dataformat och datatyper
• Tillhandahålla ursprung antingen genom att länka källsystem och integreringstjänster till skannrar eller genom att manuellt tillhandahålla ursprung
• Följa datadelningsuppgifter, inklusive IAM-åtkomstgranskningar och skapande av datakontrakt

Kornighetsnivå för avkoppling

Nu när du vet hur du känner igen och underlättar datadomäner kan du lära dig att utforma rätt nivå av domänkornighet och regler för avkoppling. Två viktiga dimensioner är i spel när du delar upp arkitekturen.

Kornighet för funktionella domäner och inställning av begränsade kontexter är en dimension. Domäner följer ett visst sätt att arbeta, vilket säkerställer att data blir tillgängliga för alla domäner som använder delade tjänster, tar ägarskap, följer metadatastandarder och så vidare.

Ange detaljerade gränser där det är möjligt för datadistribution. Att bli datadriven handlar om att göra data tillgängliga för intensiv återanvändning. Om du gör gränserna för lösa framtvingar du oönskade kopplingar mellan många program och förlorar dataåteranvändning. Sträva efter att ta bort kopplingen varje gång data korsar gränserna för affärsfunktioner. Inom en domän tillåts nära koppling inom domänens inre arkitektur. Men när de passerar gränserna för affärsfunktioner måste domänerna förbli frikopplade och distribuera läsoptimerade dataprodukter för delning med andra domäner.

Kornighet för tekniska domäner och infrastrukturanvändning är den andra viktiga dimensionen. Dina datalandningszoner möjliggör flexibilitet för service av dataprogram som skapar dataprodukter. Hur skapar du den här typen av landningszon med delad infrastruktur och tjänster under? Funktionella domäner grupperas logiskt och är bra kandidater för att dela plattformsinfrastruktur. Här följer några faktorer att tänka på när du skapar dessa landningszoner:

• Sammanhållning och effektivitet när du arbetar med och delar data är en stark drivkraft för att anpassa funktionella domäner till en datalandningszon. Detta gäller datagravitation, tendensen att ständigt dela stora dataprodukter mellan domäner.
• Regionala gränser kan leda till att extra datalandningszoner implementeras.
• Ägarskap, säkerhet eller juridiska gränser kan tvinga domänsegregering. Vissa data kan till exempel inte vara synliga för andra domäner.
• Flexibilitet och förändringstakten är viktiga faktorer. Vissa domäner kan ha en hög hastighet av innovation, medan andra domäner starkt värdesätter stabilitet.
• Funktionella gränser kan driva team isär. Ett exempel på detta kan vara källorienterade och konsumentorienterade gränser. Hälften av dina domänteam kan värdera vissa tjänster framför andra.
• Om du vill kunna sälja eller separera din funktion bör du undvika att integrera nära med delade tjänster från andra domäner.
• Teamstorlek, färdigheter och mognad kan alla vara viktiga faktorer. Högkvalificerade och mogna team föredrar ofta att använda sina egna tjänster och infrastruktur, medan mindre mogna team är mindre benägna att värdera de extra kostnaderna för plattformsunderhåll.

Innan du etablerar många datalandningszoner bör du titta på domänens nedbrytning och avgöra vilka funktionella domäner som är kandidater för delning av underliggande infrastruktur.

Sammanfattning

Modellering av affärsfunktioner hjälper dig att bättre identifiera och organisera dina domäner i en datanätsarkitektur. Det ger en holistisk vy över hur data och program levererar värde till din verksamhet, samtidigt som du hjälper dig att prioritera och fokusera på din datastrategi och dina affärsbehov. Du kan också använda modellering av affärsfunktioner för mer än bara data. Om skalbarhet till exempel är ett problem kan du använda den här modellen för att identifiera dina mest kritiska kärnfunktioner och utveckla en strategi för dem.

Vissa utövare oroar sig för att det är en intensiv övning att skapa målstatsarkitektur genom att mappa allt i förväg. De föreslår i stället att du identifierar dina domäner organiskt när du registrerar dem i din nya datanätarkitektur. I stället för att definiera måltillståndet uppifrån och ned arbetar du nedifrån och upp, utforskar, experimenterar och övergår ditt aktuella tillstånd till ett måltillstånd. Även om detta föreslagna tillvägagångssätt kan vara snabbare, medför det betydande risker. Du kan enkelt vara mitt i en komplex flytt- eller ombyggnadsåtgärd när saker börjar gå sönder. Att arbeta från båda hållen, uppifrån och ned och ned och sedan mötas i mitten över tid är en mer nyanserad metod.

Gå vidare

• Vad är en dataprodukt?