Grenzen van domeinmodellen voor elke microservice identificeren

Aanbeveling

Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Het doel bij het identificeren van modelgrenzen en -grootte voor elke microservice is niet om de meest gedetailleerde scheiding mogelijk te krijgen, hoewel u indien mogelijk naar kleine microservices moet gaan. In plaats daarvan moet uw doel zijn om de meest zinvolle scheiding te bereiken die wordt geleid door uw domeinkennis. De nadruk ligt niet op de grootte, maar op zakelijke mogelijkheden. Als er bovendien een duidelijke samenhang nodig is voor een bepaald gebied van de toepassing op basis van een groot aantal afhankelijkheden, geeft dat ook aan dat er één microservice nodig is. Cohesie is een manier om te bepalen hoe microservices uit elkaar kunnen worden gehaald of gegroepeerd. Uiteindelijk moet u, terwijl u meer kennis over het domein krijgt, de grootte van uw microservice iteratief aanpassen. Het vinden van de juiste grootte is geen eenmalig proces.

Sam Newman, een erkende organisator van microservices en auteur van het boek Building Microservices, markeert dat u uw microservices moet ontwerpen op basis van het patroon Bounded Context (BC) (onderdeel van domeingestuurd ontwerp), zoals eerder is geïntroduceerd. Soms kan een BC bestaan uit verschillende fysieke services, maar niet andersom.

Een domeinmodel met specifieke domeinentiteiten is van toepassing binnen een concrete BC of microservice. Een BC begrenst de toepasbaarheid van een domeinmodel en geeft ontwikkelaarsteamleden een duidelijk en gedeeld begrip van wat samenhang moet hebben en wat onafhankelijk kan worden ontwikkeld. Dit zijn dezelfde doelen voor microservices.

Een ander hulpmiddel dat uw ontwerpkeuze informeert, is de wet van Conway, waarin staat dat een toepassing de sociale grenzen van de organisatie weerspiegelt die het heeft geproduceerd. Maar soms is het tegenovergestelde waar -the de organisatie van het bedrijf wordt gevormd door de software. Mogelijk moet u de wet van Conway omkeren en de grenzen opbouwen zoals u wilt dat het bedrijf wordt georganiseerd, leunend op business process consulting.

Als u gebonden contexten wilt identificeren, kunt u een DDD-patroon gebruiken dat het patroon Contexttoewijzing wordt genoemd. Met contexttoewijzing identificeert u de verschillende contexten in de toepassing en de bijbehorende grenzen. Het is gebruikelijk om een andere context en grens te hebben voor elk klein subsysteem, bijvoorbeeld. De contextkaart is een manier om die grenzen tussen domeinen te definiëren en expliciet te maken. Een BC is autonoom en bevat de details van één domein -details, zoals bijvoorbeeld de domeinentiteiten, en definieert integratiecontracten met andere BC's. Dit is vergelijkbaar met de definitie van een microservice: het is autonoom, implementeert bepaalde domeinfunctionaliteit en moet interfaces bieden. Dit is de reden waarom contexttoewijzing en het patroon Gebonden context goede benaderingen zijn voor het identificeren van de grenzen van het domeinmodel van uw microservices.

Wanneer u een grote toepassing ontwerpt, ziet u hoe het domeinmodel kan worden gefragmenteerd. Een domeinexpert van het catalogusdomein noemt entiteiten anders in de catalogus- en inventarisdomeinen dan bijvoorbeeld een verzenddomeinexpert. Of de entiteit van het gebruikersdomein kan verschillen in grootte en aantal kenmerken bij het omgaan met een CRM-expert die elk detail van de klant wil opslaan dan voor een orderdomeinexpert die alleen gedeeltelijke gegevens over de klant nodig heeft. Het is erg moeilijk om alle domeintermen in alle domeinen die betrekking hebben op een grote toepassing, te verduidelijken. Maar het belangrijkste is dat u de termen niet wilt samenvoegen. Accepteer in plaats daarvan de verschillen en rijkdom die door elk domein worden geboden. Als u probeert een uniforme database voor de hele toepassing op te zetten, zullen pogingen tot een uniforme woordenlijst ongemakkelijk zijn en niet juist klinken voor de verschillende domeinexperts. Daarom zullen BC's (geïmplementeerd als microservices) helpen om duidelijk te maken waar u bepaalde domeintermen kunt gebruiken en waar u het systeem moet opsplitsen en extra BC's met verschillende domeinen moet maken.

U weet dat u de juiste grenzen en grootten van elk BC- en domeinmodel hebt als u weinig sterke relaties tussen domeinmodellen hebt en u doorgaans geen gegevens uit meerdere domeinmodellen hoeft samen te voegen bij het uitvoeren van typische toepassingsbewerkingen.

Misschien is het beste antwoord op de vraag hoe groot een domeinmodel voor elke microservice moet zijn: het moet een autonome BC hebben, zo geïsoleerd mogelijk, waarmee u kunt werken zonder voortdurend over te schakelen naar andere contexten (modellen van andere microservices). In afbeelding 4-10 ziet u hoe meerdere microservices (meerdere pc's) elk hun eigen model hebben en hoe hun entiteiten kunnen worden gedefinieerd, afhankelijk van de specifieke vereisten voor elk van de geïdentificeerde domeinen in uw toepassing.

Afbeelding 4-10. Entiteiten en microservicemodelgrenzen identificeren

Afbeelding 4-10 illustreert een voorbeeldscenario met betrekking tot een onlinevergaderingbeheersysteem. Dezelfde entiteit wordt weergegeven als 'Users', 'Buyers', 'Payers' en 'Customers', afhankelijk van de gebonden context. U hebt verschillende BC's geïdentificeerd die kunnen worden geïmplementeerd als microservices, op basis van domeinen die door domeinexperts voor u zijn gedefinieerd. Zoals u kunt zien, zijn er entiteiten die slechts in één microservicemodel aanwezig zijn, zoals Betalingen in de betalingsmicroservice. Deze zijn eenvoudig te implementeren.

Mogelijk hebt u echter ook entiteiten die een andere vorm hebben, maar dezelfde identiteit delen in de meerdere domeinmodellen van de meerdere microservices. De entiteit Gebruiker wordt bijvoorbeeld geïdentificeerd in de microservice Vergaderingenbeheer. Dezelfde gebruiker, met dezelfde identiteit, is degene met de naam Kopers in de Microservice Bestellen, of degene met de naam Payer in de payment microservice, en zelfs de gebruiker met de naam Klant in de microservice van de klantenservice. Dit komt doordat, afhankelijk van de alomtegenwoordige taal die elke domeinexpert gebruikt, een gebruiker mogelijk een ander perspectief heeft, zelfs met verschillende kenmerken. De gebruikersentiteit in het microservicemodel met de naam Conferences Management heeft mogelijk de meeste persoonlijke gegevenskenmerken. Diezelfde gebruiker in de vorm van Payer in de microserviceBetaling of in de vorm van Klant in de microservice Customer Service heeft mogelijk niet dezelfde lijst met kenmerken nodig.

Een vergelijkbare benadering wordt geïllustreerd in afbeelding 4-11.

Afbeelding 4-11. Traditionele gegevensmodellen opsplitsen in meerdere domeinmodellen

Wanneer u een traditioneel gegevensmodel uitsplitst tussen gebonden contexten, kunt u verschillende entiteiten hebben die dezelfde identiteit delen (een koper is ook een gebruiker) met verschillende kenmerken in elke gebonden context. U kunt zien hoe de gebruiker aanwezig is in het microservicemodel Conferentiesbeheer als de entiteit Gebruiker en ook aanwezig is in de vorm van de entiteit Koper in de microservice Prijzen, met alternatieve kenmerken of details over de gebruiker wanneer het daadwerkelijk een koper is. Voor elke microservice of BC zijn mogelijk niet alle gegevens nodig die betrekking hebben op een gebruikersentiteit, slechts een deel ervan, afhankelijk van het probleem dat moet worden opgelost of de context. In het prijs-bepalende microservicemodel hebt u bijvoorbeeld niet het adres of de naam van de gebruiker nodig, alleen de id (als identiteit) en status, die invloed hebben op kortingen bij het bepalen van prijzen van stoelen per kopers.

De Seat-entiteit heeft dezelfde naam, maar verschillende kenmerken in elk domeinmodel. Seat deelt de identiteit echter op basis van dezelfde ID, zoals gebeurt met Gebruiker en Koper.

In principe is er een gedeeld concept van een gebruiker die bestaat in meerdere services (domeinen), die allemaal de identiteit van die gebruiker delen. Maar in elk domeinmodel zijn er mogelijk aanvullende of andere gegevens over de gebruikersentiteit. Daarom moet er een manier zijn om een gebruikersentiteit van het ene domein (microservice) toe te wijzen aan een ander domein.

Er zijn verschillende voordelen om niet dezelfde gebruikersentiteit te delen met hetzelfde aantal kenmerken in domeinen. Een voordeel is om duplicatie te verminderen, zodat microservicemodellen geen gegevens bevatten die ze niet nodig hebben. Een ander voordeel is het hebben van een primaire microservice die eigenaar is van een bepaald type gegevens per entiteit, zodat updates en query's voor dat type gegevens alleen worden aangestuurd door die microservice.

VorigeVolgende