Identifiera domänmodellgränser för varje mikrotjänst

Dricks

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

Målet när du identifierar modellgränser och storlek för varje mikrotjänst är inte att komma till den mest detaljerade separationen som möjligt, även om du bör tendera att använda små mikrotjänster om möjligt. I stället bör målet vara att komma till den mest meningsfulla separationen som styrs av dina domänkunskaper. Betoningen ligger inte på storleken, utan på affärsfunktionerna. Om det finns en tydlig sammanhållning som behövs för ett visst område i programmet baserat på ett stort antal beroenden, anger det också behovet av en enda mikrotjänst. Sammanhållning är ett sätt att identifiera hur man delar upp eller grupperar mikrotjänster. I slutändan, medan du får mer kunskap om domänen, bör du anpassa storleken på din mikrotjänst, iterativt. Att hitta rätt storlek är inte en engångsprocess.

Sam Newman, en erkänd arrangör av mikrotjänster och författare till boken Building Microservices, markerar att du bör utforma dina mikrotjänster baserat på mönstret Bounded Context (BC) (en del av domändriven design), som introducerades tidigare. Ibland kan bc bestå av flera fysiska tjänster, men inte tvärtom.

En domänmodell med specifika domänentiteter gäller inom en konkret BC- eller mikrotjänst. En BC avgränsar tillämpligheten för en domänmodell och ger utvecklarteamets medlemmar en tydlig och delad förståelse för vad som måste vara sammanhängande och vad som kan utvecklas oberoende av varandra. Det här är samma mål för mikrotjänster.

Ett annat verktyg som informerar ditt designval är Conways lag, som säger att ett program kommer att återspegla de sociala gränserna för den organisation som producerade den. Men ibland är motsatsen sant - företagets organisation bildas av programvaran. Du kan behöva upphäva Conways lag och bygga gränserna som du vill att företaget ska organiseras och luta sig mot affärsprocesskonsultation.

Om du vill identifiera avgränsade kontexter kan du använda ett DDD-mönster som kallas kontextmappningsmönster. Med Kontextmappning identifierar du de olika kontexterna i programmet och deras gränser. Det är vanligt att ha en annan kontext och gräns för varje litet undersystem, till exempel. Kontextkartan är ett sätt att definiera och göra dessa gränser explicita mellan domäner. En BC är autonom och innehåller information om en enda domän – information som domänentiteter – och definierar integreringskontrakt med andra BC:er. Detta liknar definitionen av en mikrotjänst: den är autonom, implementerar vissa domänfunktioner och måste tillhandahålla gränssnitt. Det är därför kontextmappning och mönstret Begränsad kontext är bra metoder för att identifiera domänmodellens gränser för dina mikrotjänster.

När du utformar ett stort program ser du hur dess domänmodell kan fragmenteras – en domänexpert från katalogdomänen namnger entiteter på ett annat sätt i katalog- och inventeringsdomänerna än en fraktdomänexpert, till exempel. Eller så kan entiteten för användardomänen vara annorlunda i storlek och antal attribut när du hanterar en CRM-expert som vill lagra alla detaljer om kunden än för en beställande domänexpert som bara behöver partiella data om kunden. Det är mycket svårt att skilja alla domäntermer åt alla domäner som är relaterade till ett stort program. Men det viktigaste är att du inte ska försöka förena villkoren. Acceptera i stället skillnaderna och rikedomen som tillhandahålls av varje domän. Om du försöker ha en enhetlig databas för hela programmet blir försök till ett enhetligt ordförråd besvärliga och låter inte rätt för någon av de flera domänexperterna. Därför hjälper BCs (implementerade som mikrotjänster) dig att klargöra var du kan använda vissa domänvillkor och var du behöver dela upp systemet och skapa ytterligare BC:er med olika domäner.

Du vet att du har rätt gränser och storlekar för varje BC- och domänmodell om du har få starka relationer mellan domänmodeller, och du vanligtvis inte behöver slå samman information från flera domänmodeller när du utför vanliga programåtgärder.

Det kanske bästa svaret på frågan om hur stor en domänmodell för varje mikrotjänst ska vara är följande: den bör ha en autonom BC, så isolerad som möjligt, som gör att du kan arbeta utan att ständigt behöva byta till andra kontexter (andra mikrotjänstmodeller). I bild 4–10 kan du se hur flera mikrotjänster (flera BC) var och en har sin egen modell och hur deras entiteter kan definieras, beroende på de specifika kraven för var och en av de identifierade domänerna i ditt program.

Bild 4-10. Identifiera entiteter och gränser för mikrotjänstmodeller

Bild 4–10 visar ett exempelscenario som rör ett onlinekonferenshanteringssystem. Samma entitet visas som "Användare", "Köpare", "Betalare" och "Kunder" beroende på den avgränsade kontexten. Du har identifierat flera BC:er som kan implementeras som mikrotjänster, baserat på domäner som domänexperter har definierat åt dig. Som du ser finns det entiteter som bara finns i en enda mikrotjänstmodell, som Betalningar i mikrotjänsten Betalning. De kommer att vara lätta att genomföra.

Men du kan också ha entiteter som har en annan form men som delar samma identitet i flera domänmodeller från flera mikrotjänster. Entiteten Användare identifieras till exempel i mikrotjänsten Konferenshantering. Samma användare, med samma identitet, är den som heter Köpare i mikrotjänsten Ordering, eller den som heter Payer i mikrotjänsten Payment, och till och med den som heter Customer i customer service-mikrotjänsten. Det beror på att en användare kan ha olika perspektiv även med olika attribut, beroende på vilket språk varje domänexpert använder. Användarentiteten i mikrotjänstmodellen med namnet Conferences Management kan ha de flesta av sina personliga dataattribut. Samma användare i form av Payer i mikrotjänstbetalningen eller i form av Kunden i mikrotjänstens kundtjänst kanske inte behöver samma lista med attribut.

En liknande metod illustreras i bild 4–11.

Bild 4-11. Dela upp traditionella datamodeller i flera domänmodeller

När du delar upp en traditionell datamodell mellan avgränsade kontexter kan du ha olika entiteter som delar samma identitet (en köpare är också en användare) med olika attribut i varje begränsad kontext. Du kan se hur användaren finns i mikrotjänstmodellen Konferenshantering som användarentitet och även finns i form av entiteten Köpare i mikrotjänsten Prissättning, med alternativa attribut eller information om användaren när den faktiskt är en köpare. Varje mikrotjänst eller BC kanske inte behöver alla data som är relaterade till en användarentitet, bara en del av den, beroende på problemet som ska lösas eller kontexten. I mikrotjänstmodellen Prissättning behöver du till exempel inte adressen eller namnet på användaren, bara ID:t (som identitet) och Status, vilket påverkar rabatterna när du prissätter platserna per köpare.

Seat-entiteten har samma namn men olika attribut i varje domänmodell. Seat delar dock identitet baserat på samma ID, vilket händer med användare och köpare.

I grund och botten finns det ett delat begrepp för en användare som finns i flera tjänster (domäner), som alla delar användarens identitet. Men i varje domänmodell kan det finnas ytterligare eller olika detaljer om användarentiteten. Därför måste det finnas ett sätt att mappa en användarentitet från en domän (mikrotjänst) till en annan.

Det finns flera fördelar med att inte dela samma användarentitet med samma antal attribut mellan domäner. En fördel är att minska dupliceringen så att mikrotjänstmodeller inte har några data som de inte behöver. En annan fördel är att ha en primär mikrotjänst som äger en viss typ av data per entitet så att uppdateringar och frågor för den typen av data endast drivs av den mikrotjänsten.

FöregåendeNästa