Gegevensdomeinen

Data mesh is fundamenteel gebaseerd op decentralisatie en de verdeling van verantwoordelijkheid voor domeinen. Als u echt een deel van het bedrijf begrijpt, kunt u de bijbehorende gegevens het beste beheren en de nauwkeurigheid ervan garanderen. Dit is het principe van domeingeoriënteerd gegevenseigendom.

Als u het eigendom van domeingeoriënteerde gegevens wilt promoten, moet u eerst uw gegevensarchitectuur decomponeren. De data mesh-oprichter, Zhamak Dehgany, bevordert de Domain-Driven Design -benadering (DDD) voor softwareontwikkeling als een handige methode om u te helpen uw gegevensdomeinen te identificeren.

Het probleem met het gebruik van DDD voor gegevensbeheer is dat de oorspronkelijke use-case van DDD complexe systemen modelleerde in een softwareontwikkelingscontext. Het is niet oorspronkelijk gemaakt om zakelijke gegevens te modelleren en voor gegevensbeheerbeoefenaars kan de methode abstract en technisch zijn. Er is vaak een gebrek aan begrip van DDD. Beoefenaars vinden de conceptuele concepten te moeilijk te begrijpen of proberen voorbeelden van softwarearchitectuur of objectgeoriënteerde programmering op hun gegevenslandschap te projecteren. Dit artikel bevat pragmatische richtlijnen en duidelijke woordenlijst, zodat u DDD kunt begrijpen en gebruiken.

Domeingestuurd ontwerp

Geïntroduceerd door Eric Evans, Domain-Driven Design is een methode voor het ondersteunen van softwareontwikkeling waarmee complexe systemen voor grotere organisaties worden beschreven. DDD is populair omdat veel van de procedures op hoog niveau van invloed zijn op moderne software- en toepassingsontwikkelingsmethoden, zoals microservices.

DDD maakt onderscheid tussen gebonden contexten, domeinen en subdomeinen. Domeinen zijn probleemruimten die u wilt oplossen. Ze zijn gebieden waar kennis, gedrag, wetten en activiteiten samenkomen. U ziet semantische koppeling in domeinen, gedragsafhankelijkheden tussen onderdelen of services. Een ander aspect van domeinen is communicatie. Teamleden moeten een taal gebruiken die het hele team deelt, zodat iedereen efficiënt kan werken. Deze gedeelde taal wordt de alomtegenwoordige taal of domeintaalgenoemd.

Domeinen worden opgesplitst in subdomeinen om de complexiteit beter te beheren. Een veelvoorkomend voorbeeld hiervan is het opsplitsen van een domein in subdomeinen die elk overeenkomen met één specifiek bedrijfsprobleem, zoals wordt weergegeven in Data Mesh operationeel maken voor AI/ML-.

Niet alle subdomeinen zijn hetzelfde. U kunt bijvoorbeeld domeinen classificeren als kern, algemeen of ondersteunend. Kernsubdomeinen zijn de belangrijkste. Ze zijn de geheime saus, de ingrediënten, die een organisatie uniek maken. Algemene subdomeinen zijn niet specifiek en meestal gemakkelijk op te lossen met kant-en-klare producten. Het ondersteunen van subdomeinen biedt geen concurrentievoordeel, maar is noodzakelijk om een organisatie actief te houden en niet complex te zijn.

Gebonden contexten zijn logische (context) grenzen. Ze richten zich op de oplossingsruimte: het ontwerp van systemen en toepassingen. Het is een gebied waar de uitlijning van de focus op de oplossingsruimte zinvol is. Binnen DDD kan dit code, databaseontwerpen, enzovoort bevatten. Tussen de domeinen en gebonden contexten kan er uitlijning zijn, maar er is geen vaste regel die de twee met elkaar verbindt. Gebonden contexten zijn van nature technisch en kunnen meerdere domeinen en subdomeinen omvatten.

Aanbevelingen voor domeinmodellering

Hoe werkt dit in de praktijk als u data mesh gebruikt als concept voor data-democratisering en het principe van domeingericht gegevenseigendom implementeert om de flexibiliteit te vergroten? Hoe kan een overgang van enterprise-gegevensmodellering naar modellering op basis van een domein eruit zien? Welke lessen kunt u nemen van DDD voor gegevensbeheer?

Een functionele bedrijfsontleding van uw probleemruimten maken

Voordat u uw teams hun gegevens end-to-end laat beheren, kijkt u naar de omvang en begrijpt u de probleemgebieden die u probeert op te lossen. Het is belangrijk om deze oefening eerst uit te voeren voordat u begint met de details van een technische implementatie. Wanneer u logische grenzen tussen deze probleemruimten instelt, worden verantwoordelijkheden duidelijker en kunnen ze beter worden beheerd.

Bekijk uw bedrijfsarchitectuur bij het groeperen van uw probleemruimten. Binnen bedrijfsarchitectuur zijn er bedrijfsvaardigheden: capaciteiten of vermogens die een bedrijf bezit of uitwisselt om een specifiek doel of resultaat te bereiken. Deze abstractie verpakt gegevens, processen, organisatie en technologie in een bepaalde context, in overeenstemming met de strategische bedrijfsdoelen en -doelstellingen van uw organisatie. Een kaart met bedrijfsfuncties laat zien welke functionele gebieden nodig zijn om uw missie en visie te vervullen.

U kunt de capabiliteitsdecompositie van een fictief bedrijf, Tailwind Traders, bekijken in het volgende model.

Tailwind Traders moet alle functionele gebieden beheren die worden vermeld in de Business Capability Map om succesvol te zijn. Tailwind Traders moet tickets kunnen verkopen als onderdeel van Online- of Offline Tickets Management Systems, of piloten hebben die beschikbaar zijn voor vliegvliegtuigen als onderdeel van een Pilot Management Program. Het bedrijf kan bepaalde activiteiten uitbesteden en anderen behouden als de kern van haar bedrijf.

Wat u in de praktijk ziet, is dat de meeste van uw mensen zijn georganiseerd rond bedrijfsmogelijkheden. Mensen die aan dezelfde zakelijke mogelijkheden werken, hebben dezelfde woordenlijst. Hetzelfde geldt voor uw toepassingen en processen, die doorgaans goed zijn afgestemd en nauw verbonden zijn op basis van de samenhang van activiteiten die ze ondersteunen.

Het in kaart brengen van bedrijfscompetenties is een goed beginpunt, maar uw verhaal eindigt hier niet.

Bedrijfsmogelijkheden toewijzen aan toepassingen en gegevens

Als u uw bedrijfsarchitectuur beter wilt beheren, moet u uw bedrijfsmogelijkheden, gebonden contexten en toepassingen uitlijnen. Het is belangrijk om een aantal grondregels te volgen zoals u dat doet.

Bedrijfsmogelijkheden moeten op bedrijfsniveau blijven en abstract blijven. Ze vertegenwoordigen wat uw organisatie doet en richt zich op uw probleemruimten. Wanneer u een bedrijfsmogelijkheid implementeert, wordt er een realisatie (capaciteitsexemplaren) voor een specifieke context gemaakt. Meerdere toepassingen en onderdelen werken samen binnen dergelijke grenzen in uw oplossingsruimte om specifieke bedrijfswaarde te leveren.

Toepassingen en onderdelen die zijn afgestemd op een bepaalde bedrijfsmogelijkheid, blijven losgekoppeld van toepassingen die zijn afgestemd op andere bedrijfsmogelijkheden, omdat ze verschillende zakelijke problemen aanpakken. Gebonden contexten worden afgeleid van en exclusief toegewezen aan bedrijfsmogelijkheden. Ze vertegenwoordigen de grens van een implementatie van bedrijfsfuncties en gedragen zich als een domein.

Als de bedrijfsmogelijkheden veranderen, veranderen gebonden contexten. U verwacht bij voorkeur volledige uitlijning tussen domeinen en bijbehorende gebonden contexten, maar zoals u in latere secties leert, verschilt de realiteit soms van het ideale.

Als we mogelijkheden toewijzen aan Tailwind Traders, kunnen gebonden contextgrenzen en domein implementaties er ongeveer uitzien als in het volgende diagram.

In dit diagram is Customer Management gebaseerd op expertise op het gebied van zaken en weet daarom het beste welke gegevens voor andere domeinen moeten dienen. De interne architectuur van Customer Management is losgekoppeld, zodat alle toepassingsonderdelen binnen deze grenzen rechtstreeks kunnen communiceren met behulp van toepassingsspecifieke interfaces en gegevensmodellen.

Gegevensproducten en duidelijke interoperabiliteitsstandaarden worden gebruikt om gegevensdistributie naar andere domeinen te formaliseren. In deze benadering komen alle gegevensproducten ook overeen met het domein en nemen ze de alomtegenwoordige taal over, een geconstrueerde, geformaliseerde taal die is overeengekomen door belanghebbenden en ontwerpers uit hetzelfde domein, om de behoeften van dat domein te kunnen dienen.

Extra domeinen van meerdere capabiliteitsrealisaties

Het is belangrijk te erkennen dat sommige bedrijfscapaciteiten meerdere keren kunnen worden geïnstantieerd bij het werken met bedrijfscapaciteitkaarten.

Tailwind Traders kan bijvoorbeeld meerdere gelokaliseerde realisaties (of implementaties) hebben van 'bagageafhandeling en verloren items'. Stel dat één lijn van hun bedrijf alleen in Azië werkt. In deze context is "bagageafhandeling en verloren items" een mogelijkheid die wordt vervuld voor azië gerelateerde vliegtuigen. Een andere line-of-business kan gericht zijn op de Europese markt, en in dit verband wordt een andere "bagageafhandeling en verloren items" mogelijkheid gebruikt. Dit scenario van meerdere exemplaren kan leiden tot meerdere gelokaliseerde implementaties met behulp van verschillende technologieservices en niet-aaneengesloten teams om deze services te gebruiken.

De relatie tussen zakelijke mogelijkheden en capaciteitsexemplaren (realisaties) is een-op-veel. Hierdoor krijgt u uiteindelijk extra (sub-) domeinen.

Gedeelde mogelijkheden zoeken en letten op gedeelde gegevens

Hoe u met gedeelde bedrijfsmogelijkheden omgaat, is belangrijk. Doorgaans implementeert u gedeelde mogelijkheden centraal, als servicemodellen en biedt u ze aan verschillende bedrijfslijnen. 'Customer Management' kan een voorbeeld zijn van dit soort mogelijkheden. In ons voorbeeld van Tailwind Traders gebruiken zowel de Aziatische als de Europese bedrijfslijnen hetzelfde beheer voor hun klanten.

Maar hoe kunt u het eigendom van domeingegevens op een gedeelde mogelijkheid projecteren? Meerdere bedrijfsvertegenwoordigers nemen waarschijnlijk verantwoordelijkheid voor klanten binnen hetzelfde gedeelde beheer.

Er is een toepassingsdomein en een gegevensdomein. Uw domein en gebonden context worden niet perfect uitgelijnd vanuit het oogpunt van een gegevensproduct. U kunt daarentegen beweren dat er nog steeds één gegevensprobleem is vanuit het oogpunt van bedrijfsfunctionaliteit.

Voor gedeelde mogelijkheden, zoals complexe leverancierspakketten, SaaS-oplossingen en verouderde systemen, moet u consistent zijn in uw aanpak voor het eigendom van domeingegevens. U kunt het eigendom van gegevens scheiden via gegevensproducten, waarvoor mogelijk toepassingsverbeteringen zijn vereist. In ons voorbeeld 'Customer Management' van Tailwind Traders kunnen verschillende pijplijnen van het toepassingsdomein meerdere gegevensproducten genereren: één gegevensproduct voor alle klanten in Azië en één voor alle Europese klanten. In dit geval zijn meerdere gegevensdomeinen afkomstig uit hetzelfde toepassingsdomein.

U kunt uw toepassingsdomeinen ook vragen om één gegevensproduct te maken dat metagegevens inkapselt om het eigendom van gegevens binnen zichzelf te onderscheiden. U kunt bijvoorbeeld een kolomnaam reserveren voor eigendom, elke rij toewijzen aan één specifiek gegevensdomein.

Monoliths identificeren die meerdere zakelijke mogelijkheden bieden

Let ook op toepassingen die geschikt zijn voor meerdere zakelijke mogelijkheden, die vaak worden gezien in grote en traditionele ondernemingen. In ons voorbeeldscenario gebruikt Tailwind Traders een complex softwarepakket om zowel 'kostenbeheer' als 'assets en financiering' te vergemakkelijken. Deze gedeelde toepassingen zijn monolithen die zoveel mogelijk functies bieden, waardoor ze groot en complex zijn. In een dergelijke situatie moet het toepassingsdomein groter zijn. Hetzelfde geldt voor gedeeld eigendom, waarin verschillende gegevensdomeinen zich in een toepassingsdomein bevinden.

Ontwerppatronen voor op bron uitgelijnde, opnieuw uitgelijnde domeinen en op consumenten afgestemde domeinen

Wanneer u uw domeinen toewijst, kunt u een patroon kiezen op basis van de creatie, consumptie of herlevering van uw gegevens. Voor uw architectuur kunt u sjablonen ontwerpen die ondersteuning bieden voor uw domeinen op basis van de specifieke kenmerken van het domein.

Domeinen afgestemd op het bronsysteem

Op het bronsysteem uitgelijnde domeinen worden afgestemd op bronsystemen waar gegevens vandaan komen. Deze systemen zijn doorgaans transactioneel of operationeel.

Het doel is om gegevens rechtstreeks vanuit deze gouden bronsystemen vast te leggen. Gegevensproducten die zijn geoptimaliseerd voor lezen uit uw domeinen voor intensief gegevensverbruik. Faciliteer deze domeinen met behulp van gestandaardiseerde services voor gegevenstransformatie en -delen.

Met deze services, waaronder vooraf geconfigureerde containerstructuren, kunnen uw brongerichte domeinteams gegevens eenvoudiger publiceren. Het is het pad van minimale weerstand met minimale onderbrekingen en kosten.

Consumentgerichte domeinen

Door de consument uitgelijnde domeinen zijn het tegenovergestelde van op de bron afgestemde domeinen. Ze zijn afgestemd op specifieke gebruiksscenario's van eindgebruikers die gegevens van andere domeinen vereisen. Door de klant uitgelijnde domeinen gebruiken en transformeren gegevens zodat ze passen bij de gebruiksscenario's van uw organisatie.

Overweeg gedeelde gegevensservices aan te bieden voor gegevenstransformatie en -verbruik om tegemoet te komen aan deze verbruiksbehoeften. U kunt bijvoorbeeld mogelijkheden voor domeinonafhankelijke gegevensinfrastructuur bieden, bijvoorbeeld voor het afhandelen van gegevenspijplijnen, opslaginfrastructuur, streamingservices, analytische verwerking, enzovoort.

Redelivery-domeinen

De herbruikbaarheid van gegevens is een ander en moeilijker scenario. Als downstreamgebruikers bijvoorbeeld geïnteresseerd zijn in een combinatie van gegevens uit verschillende domeinen, kunt u gegevensproducten maken die gegevens aggregeren of gegevens op hoog niveau combineren die vereist zijn voor veel domeinen. Zo voorkomt u terugkerende werkzaamheden.

Maak geen sterke afhankelijkheden tussen uw gegevensproducten en analytische gebruiksvoorbeelden. Streven naar flexibiliteit en losse koppeling in plaats daarvan. Het volgende model laat zien hoe u flexibiliteit kunt bereiken. Een domein is eigenaar van zowel gegevensproducten als analytische gebruiksvoorbeelden en heeft afzonderlijke processen ontworpen voor het maken van gegevensproducten en het gegevensgebruik.

Overlappende domeinpatronen definiëren

Domeinmodellering wordt vaak ingewikkeld wanneer gegevens of bedrijfslogica worden gedeeld tussen domeinen. In grote organisaties zijn domeinen vaak afhankelijk van gegevens uit andere domeinen. Het kan handig zijn om algemene domeinen te hebben die integratielogica bieden op een manier waarmee andere subdomeinen deze kunnen standaardiseren en hiervan kunnen profiteren. Houd uw gedeelde model tussen subdomeinen klein en altijd uitgelijnd met de alomtegenwoordige taal.

Voor overlappende gegevensvereisten kunt u verschillende patronen gebruiken in het ontwerp op basis van een domein. Hier volgt een kort overzicht van de patronen waaruit u kunt kiezen:

• Een afzonderlijke manieren patroon kan worden gebruikt als u de bijbehorende kosten van duplicatie ten opzichte van herbruikbaarheid wilt. Herbruikbaarheid wordt opgeofferd voor hogere flexibiliteit en wendbaarheid.
• Een klant-leverancier patroon kan worden gebruikt als één domein sterk is en bereid is eigenaar te worden van de gegevens en behoeften van downstreamgebruikers. Nadelen zijn onder andere conflicterende zorgen en het dwingen van uw downstreamteams om te onderhandelen over leveringen en prioriteiten te coördineren.
• Een partnerschap patroon kan worden gebruikt wanneer uw integratielogica op een niet-geplande manier binnen een nieuw gemaakt domein wordt gecoördineerd. Alle teams werken samen met en houden rekening met elkaars behoeften. Omdat niemand de gedeelde logica vrij kan wijzigen, is een aanzienlijke inzet nodig van iedereen die erbij betrokken is.
• Een conform patroon kan worden gebruikt om al uw domeinen aan alle vereisten te voldoen. Gebruik dit patroon wanneer uw integratiewerk complex is, kunnen er geen andere partijen controle hebben of als u leverancierspakketten gebruikt.

In alle gevallen moeten uw domeinen voldoen aan uw interoperabiliteitsstandaarden. Een partnerschapsdomein dat nieuwe gegevens produceert voor andere domeinen, moet hun gegevensproducten als elk ander domein beschikbaar maken, waaronder eigendom nemen.

Domeinverantwoordelijkheden

Data mesh decentraliseert het eigendom van gegevens door deze te distribueren tussen domeinteams. Voor veel organisaties betekent dit een verschuiving van een gecentraliseerd model rond governance naar een federatief model. De domeinteams worden taken toegewezen, zoals:

• Verantwoordelijkheid nemen voor data-infrastructuur, zoals het inladen, opschonen en transformeren van gegevens, om aan zoveel mogelijk behoeften van dataklanten te voldoen.
• Verbetering van gegevenskwaliteit, waaronder naleving van SLA's en kwaliteitsmaatregelen die zijn ingesteld door gegevensgebruikers
• Metagegevens inkapselen of gereserveerde kolomnamen gebruiken voor fijnmazig filteren op rij- en kolomniveau
• Voldoen aan standaarden voor metagegevensbeheer, waaronder:
  • Registratie van toepassings- en bronsysteemschema's
  • Metagegevens voor verbeterde detectie
  • Versiebeheergegevens
  • Koppeling van gegevenskenmerken en zakelijke termen
  • Integriteit van metagegevens informatie om een betere integratie tussen domeinen mogelijk te maken
• Voldoen aan standaarden voor gegevensinteroperabiliteit, waaronder protocollen, gegevensindelingen en gegevenstypen
• Herkomst bieden door bronsystemen en integratieservices te koppelen aan scanners of door handmatig herkomst te bieden
• Het naleven van taken voor het delen van gegevens, waaronder IAM-toegangsbeoordelingen en het opstellen van een gegevenscontract

Granulariteitsniveau voor ontkoppeling

Nu u weet hoe u gegevensdomeinen kunt herkennen en vergemakkelijken, kunt u leren hoe u het juiste niveau van domeingranulariteit en regels voor ontkoppeling kunt ontwerpen. Er zijn twee belangrijke dimensies in het spel wanneer u uw architectuur ontled.

Granulariteit voor functionele domeinen en het instellen van gebonden contexten is één dimensie. Domeinen voldoen aan een bepaalde manier van werken, zodat gegevens beschikbaar worden voor alle domeinen die gebruikmaken van gedeelde services, eigendom nemen, voldoen aan metagegevensstandaarden, enzovoort.

Stel waar mogelijk fijnmazige grenzen in voor gegevensdistributie. Gegevensgestuurd worden gaat over het beschikbaar maken van gegevens voor intensief hergebruik. Als u uw grenzen te los maakt, dwingt u ongewenste koppelingen tussen veel toepassingen af en verliest u de herbruikbaarheid van gegevens. Streven naar ontkoppeling telkens wanneer gegevens grenzen van bedrijfsmogelijkheden overschrijden. Binnen een domein is strakke koppeling binnen de binnenste architectuur van het domein toegestaan. Echter, wanneer de grenzen van bedrijfsmogelijkheden worden overschreden, moeten domeinen gescheiden blijven en lees-geoptimaliseerde gegevensproducten distribueren voor delen met andere domeinen.

Granulariteit voor technische domeinen en infrastructuurgebruik is de andere belangrijke dimensie. Uw datalandingszones bieden flexibiliteit voor het onderhouden van datatoepassingen, waarmee dataproducten worden gemaakt. Hoe maakt u dit soort landingszone met gedeelde infrastructuur en services eronder? Functionele domeinen worden logisch gegroepeerd en zijn goede kandidaten voor het delen van platforminfrastructuur. Hier volgen enkele factoren waarmee u rekening moet houden bij het maken van deze landingszones:

• Cohesie en efficiëntie bij het werken met en delen van gegevens is een sterke drijvende kracht voor het afstemmen van functionele domeinen op een gegevenslandingszone. Dit heeft betrekking op de zwaartekracht van gegevens, de neiging om voortdurend grote gegevensproducten tussen domeinen te delen.
• Regionale grenzen kunnen ertoe leiden dat er extra landingszones voor gegevens worden geïmplementeerd.
• Eigendom, beveiliging of juridische grenzen kunnen domeinscheiding afdwingen. Sommige gegevens kunnen bijvoorbeeld niet zichtbaar zijn voor andere domeinen.
• Flexibiliteit en het tempo van verandering zijn belangrijke factoren. Sommige domeinen kunnen een hoge snelheid van innovatie hebben, terwijl andere domeinen de stabiliteit sterk waarderen.
• Functionele grenzen kunnen teams uit elkaar halen. Een voorbeeld hiervan is brongeoriënteerde en consumentengeoriënteerde grenzen. De helft van uw domeinteams kan waarde hebben voor bepaalde services ten opzichte van anderen.
• Als u uw mogelijkheden mogelijk wilt verkopen of scheiden, moet u voorkomen dat u nauw integreert met gedeelde services van andere domeinen.
• Teamgrootte, vaardigheden en volwassenheid kunnen allemaal belangrijke factoren zijn. Zeer ervaren en volwassen teams geven vaak de voorkeur aan hun eigen services en infrastructuur, terwijl minder volwassen teams minder waarschijnlijk de extra overhead van platformonderhoud waarderen.

Voordat u veel landingszones voor gegevens inricht, bekijkt u de decompositie van uw domein en bepaalt u welke functionele domeinen kandidaten zijn voor het delen van de onderliggende infrastructuur.

Samenvatting

Met business capability modeling kunt u uw domeinen beter herkennen en organiseren in een data mesh-architectuur. Het biedt een holistische weergave van de manier waarop gegevens en toepassingen waarde leveren aan uw bedrijf en tegelijkertijd helpen u prioriteiten te stellen en te focussen op uw gegevensstrategie en bedrijfsbehoeften. U kunt ook business capability modellering gebruiken voor meer dan alleen gegevens. Als schaalbaarheid bijvoorbeeld een probleem is, kunt u dit model gebruiken om uw meest kritieke kernmogelijkheden te identificeren en een strategie voor hen te ontwikkelen.

Sommige beoefenaars maken zich zorgen dat het bouwen van de doelarchitectuur door alles van tevoren in kaart te brengen een intensieve oefening is. Ze stellen in plaats daarvan voor dat u uw domeinen organisch identificeert terwijl u ze onboardt in uw nieuwe data mesh-architectuur. In plaats van de doelstatus van boven naar beneden te definiëren, werkt u onderaan, verkent, experimenteert en overstapt u uw huidige status naar een doelstatus. Hoewel deze voorgestelde aanpak sneller kan zijn, loopt dit aanzienlijke risico's. Het kan gemakkelijk gebeuren dat u midden in een complex verhuis- of renovatieproces zit wanneer dingen beginnen kapot te gaan. Werken vanuit beide richtingen, van boven naar beneden en van beneden naar boven, en dan geleidelijk in het midden samenkomen is een meer genuanceerde benadering.

Volgende stap

• Wat is een gegevensproduct?