Delen via


Vereenvoudigde CQRS- en DDD-patronen toepassen in een microservice

Tip

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.

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

CQRS is een architectuurpatroon dat de modellen scheidt voor het lezen en schrijven van gegevens. De gerelateerde term Command Query Separation (CQS) werd oorspronkelijk gedefinieerd door Microsoft Meyer in zijn boek Objectgeoriënteerde Software Construction. Het basisidee is dat u de bewerkingen van een systeem kunt verdelen in twee scherp gescheiden categorieën:

  • Query 's. Deze query's retourneren een resultaat en wijzigen de status van het systeem niet en zijn vrij van bijwerkingen.

  • Opdrachten. Met deze opdrachten wordt de status van een systeem gewijzigd.

CQS is een eenvoudig concept: het gaat over methoden binnen hetzelfde object als query's of opdrachten. Elke methode retourneert de status of muteert de status, maar niet beide. Zelfs één opslagplaatspatroonobject kan voldoen aan CQS. CQS kan worden beschouwd als een fundamenteel principe voor CQRS.

Command and Query Responsibility Segregation (CQRS) werd geïntroduceerd door Greg Young en werd sterk gepromoot door Udi Dahan en anderen. Het is gebaseerd op het CQS-principe, hoewel het gedetailleerder is. Het kan worden beschouwd als een patroon op basis van opdrachten en gebeurtenissen plus optioneel op asynchrone berichten. In veel gevallen is CQRS gerelateerd aan geavanceerdere scenario's, zoals het hebben van een andere fysieke database voor leesbewerkingen (query's) dan voor schrijfbewerkingen (updates). Bovendien kan een meer ontwikkeld CQRS-systeem event-sourcing (ES) implementeren voor uw updatedatabase, zodat u alleen gebeurtenissen opslaat in het domeinmodel in plaats van de huidige statusgegevens op te slaan. Deze methode wordt echter niet gebruikt in deze handleiding. In deze handleiding wordt gebruikgemaakt van de eenvoudigste CQRS-benadering, die bestaat uit het scheiden van de query's van de opdrachten.

Het scheidingsaspect van CQRS wordt bereikt door querybewerkingen in één laag en opdrachten in een andere laag te groeperen. Elke laag heeft een eigen gegevensmodel (zoals model, niet noodzakelijkerwijs een andere database) en is gebouwd met behulp van een eigen combinatie van patronen en technologieën. Belangrijker is dat de twee lagen zich binnen dezelfde laag of microservice bevinden, zoals in het voorbeeld (microservice bestellen) dat voor deze handleiding wordt gebruikt. Of ze kunnen worden geïmplementeerd op verschillende microservices of processen, zodat ze afzonderlijk kunnen worden geoptimaliseerd en uitgeschaald zonder dat dit van invloed is op elkaar.

CQRS betekent dat er twee objecten zijn voor een lees-/schrijfbewerking, waarbij er in andere contexten één object is. Er zijn redenen om een gedenormaliseerde leesdatabase te hebben, waarover u meer kunt leren in geavanceerdere CQRS-literatuur. Maar we gebruiken deze benadering hier niet, waarbij het doel is om meer flexibiliteit te hebben in de query's in plaats van de query's te beperken met beperkingen van DDD-patronen, zoals aggregaties.

Een voorbeeld van dit soort service is de bestellende microservice vanuit de referentietoepassing eShopOnContainers. Deze service implementeert een microservice op basis van een vereenvoudigde CQRS-benadering. Er wordt één gegevensbron of database gebruikt, maar twee logische modellen plus DDD-patronen voor het transactionele domein, zoals wordt weergegeven in afbeelding 7-2.

Diagram showing a high level Simplified CQRS and DDD microservice.

Afbeelding 7-2. Vereenvoudigde microservice op basis van CQRS en DDD

De logische 'Ordering' Microservice bevat de orderdatabase, die kan zijn, maar dat hoeft niet te zijn, dezelfde Docker-host. Het gebruik van de database in dezelfde Docker-host is goed voor ontwikkeling, maar niet voor productie.

De toepassingslaag kan de web-API zelf zijn. Het belangrijke ontwerpaspect hier is dat de microservice de query's en ViewModels (gegevensmodellen die speciaal zijn gemaakt voor de clienttoepassingen) heeft gesplitst van de opdrachten, het domeinmodel en transacties volgens het CQRS-patroon. Deze benadering houdt de query's onafhankelijk van beperkingen en beperkingen die afkomstig zijn van DDD-patronen die alleen zinvol zijn voor transacties en updates, zoals wordt uitgelegd in latere secties.

Aanvullende bronnen