Dela via

Tillämpa CQRS- och CQS-metoder i en DDD-mikrotjänst i eShopOnContainers

  • Artikel

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

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Utformningen av beställningsmikrotjänsten i referensprogrammet eShopOnContainers baseras på CQRS-principer. Den använder dock den enklaste metoden, som bara separerar frågorna från kommandona och använder samma databas för båda åtgärderna.

Kärnan i dessa mönster, och den viktiga punkten här, är att frågor är idempotent: oavsett hur många gånger du frågar ett system ändras inte systemets tillstånd. Med andra ord är frågor kostnadsfria med bieffekt.

Därför kan du använda en annan "reads"-datamodell än domänmodellen för transaktionslogik "skriver", även om beställningsmikrotjänsterna använder samma databas. Därför är detta en förenklad CQRS-metod.

Å andra sidan ändrar kommandon, som utlöser transaktioner och datauppdateringar, systemets tillstånd. Med kommandon måste du vara försiktig när du hanterar komplexitet och ständigt föränderliga affärsregler. Det är här du vill använda DDD-tekniker för att få ett bättre modellerat system.

DDD-mönstren som presenteras i den här guiden bör inte tillämpas universellt. De medför begränsningar för din design. Dessa begränsningar ger fördelar som högre kvalitet över tid, särskilt i kommandon och annan kod som ändrar systemtillståndet. Dessa begränsningar ökar dock komplexiteten med färre fördelar med att läsa och köra frågor mot data.

Ett sådant mönster är aggregeringsmönstret, som vi undersöker mer i senare avsnitt. I mönstret Mängd behandlar du kort många domänobjekt som en enda enhet som ett resultat av deras relation i domänen. Du kanske inte alltid får fördelar med det här mönstret i frågor. det kan öka komplexiteten i frågelogik. För skrivskyddade frågor får du inte fördelarna med att behandla flera objekt som en enda mängd. Du får bara komplexiteten.

Som du ser i bild 7-2 i föregående avsnitt föreslår den här guiden att du endast använder DDD-mönster i transaktions-/uppdateringsområdet för din mikrotjänst (det vill sa som utlöses av kommandon). Frågor kan följa en enklare metod och bör separeras från kommandon, enligt en CQRS-metod.

För att implementera "frågesidan" kan du välja mellan många metoder, från din fullständiga ORM som EF Core, AutoMapper-projektioner, lagrade procedurer, vyer, materialiserade vyer eller en mikro-ORM.

I den här guiden och i eShopOnContainers (särskilt beställande mikrotjänst) valde vi att implementera raka frågor med hjälp av en mikro-ORM som Dapper. Med den här guiden kan du implementera alla frågor baserat på SQL-instruktioner för att få bästa prestanda tack vare ett lätt ramverk med lite omkostnader.

När du använder den här metoden behöver alla uppdateringar av din modell som påverkar hur entiteter sparas i en SQL-databas också separata uppdateringar av SQL-frågor som används av Dapper eller andra separata (icke-EF) metoder för att fråga.

CQRS- och DDD-mönster är inte arkitekturer på toppnivå

Det är viktigt att förstå att CQRS och de flesta DDD-mönster (t.ex. DDD-lager eller en domänmodell med aggregeringar) inte är arkitekturformat, utan bara arkitekturmönster. Mikrotjänster, SOA och händelsedriven arkitektur (EDA) är exempel på arkitekturformat. De beskriver ett system med många komponenter, till exempel många mikrotjänster. CQRS- och DDD-mönster beskriver något inuti ett enda system eller en komponent; i det här fallet något inuti en mikrotjänst.

Olika avgränsade kontexter (BC) använder olika mönster. De har olika ansvarsområden och det leder till olika lösningar. Det är värt att betona att tvinga samma mönster överallt leder till misslyckande. Använd inte CQRS- och DDD-mönster överallt. Många undersystem, BCs eller mikrotjänster är enklare och kan implementeras enklare med hjälp av enkla CRUD-tjänster eller med hjälp av en annan metod.

Det finns bara en programarkitektur: arkitekturen för systemet eller programmet från slutpunkt till slutpunkt som du utformar (till exempel arkitekturen för mikrotjänster). Designen av varje begränsad kontext eller mikrotjänst i programmet återspeglar dock sina egna kompromisser och interna designbeslut på arkitekturmönsternivå. Försök inte använda samma arkitekturmönster som CQRS eller DDD överallt.

Ytterligare resurser

FöregåendeNästa