Overzicht van het CQRS-patroon
Leer meer over het Command Query Responsibility Segregation-patroon (CQRS) en hoe dit de schaalbaarheid en prestaties kan verbeteren.
Overzicht van het CQRS-patroon is een gratis Enterprise-backend-API's met NestJS-les op CoddyKit. Dit is les 2 van 3. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Enterprise-backend-API's met NestJS. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Enterprise-backend-API's met NestJS bevat in totaal 3 lessen.
Wat is CQRS?
Welkom! Vandaag duiken we in een krachtig architectuurpatroon met de naam CQRS. Dit staat voor Command Query Responsibility Segregation.
In de kern stelt CQRS voor dat je een ander model kunt gebruiken om informatie te bijwerken (een Command) dan het model dat je gebruikt om informatie te lezen (een Query).
Waarom verantwoordelijkheden scheiden?
In veel applicaties verschilt de manier waarop je gegevens leest sterk van de manier waarop je gegevens schrijft. Gegevensmodellen die zijn geoptimaliseerd voor schrijven (bijvoorbeeld genormaliseerde relationele databases) zijn vaak niet ideaal voor lezen (bijvoorbeeld wanneer complexe joins nodig zijn).
CQRS pakt dit aan door deze verantwoordelijkheden te scheiden, zodat elke kant onafhankelijk kan worden geoptimaliseerd voor het eigen doel.
Commands: de schrijfkant
Een Command is een object dat een intentie om de toestand te wijzigen van het systeem vertegenwoordigt. Het is een instructie om iets te doen.
- Commands zijn imperatief (bijvoorbeeld "CreateProduct" en "UpdateOrder").
- Ze mogen geen gegevens retourneren, maar alleen succes of mislukking aangeven.
- Elke command moet door precies één handler worden afgehandeld.
Hier volgt een conceptueel voorbeeld:
class CreateProductCommand {
constructor(public name: string, public price: number) {}
}Queries: de leeskant
Een Query is een object dat een verzoek om gegevens uit het systeem vertegenwoordigt. Het vraagt om informatie.
- Queries zijn declaratief (bijvoorbeeld "GetProductById" en "ListAllOrders").
- Ze mogen de toestand van het systeem niet wijzigen (geen neveneffecten).
- Queries retourneren altijd gegevens.
Hier volgt een conceptueel voorbeeld:
class GetProductByIdQuery {
constructor(public productId: string) {}
}Command-handlers
Bij elke Command hoort doorgaans een Command Handler. Deze handler is verantwoordelijk voor het aannemen van een command, het uitvoeren van de bedrijfslogica en het bijwerken van de toestand van het systeem (het schrijfmodel).
Hier bevindt zich de kernlogica van je applicatie voor het aanbrengen van wijzigingen.
class CreateProductCommandHandler {
execute(command: CreateProductCommand): void {
// Logic to create a product in the database
console.log(`Creating product: ${command.name}`);
}
}Query-handlers
Op dezelfde manier zijn Query Handlers verantwoordelijk voor het aannemen van een query en het ophalen van de gevraagde gegevens uit het leesmodel van het systeem.
Daarbij worden vaak gegevens opgehaald uit een database of andere gegevensbronnen en mogelijk omgezet naar een indeling die geschikt is voor de client.
class GetProductByIdQueryHandler {
execute(query: GetProductByIdQuery): any {
// Logic to fetch product from read model
console.log(`Fetching product with ID: ${query.productId}`);
return { id: query.productId, name: "Sample Product", price: 29.99 };
}
}Afzonderlijke gegevensmodellen
Een belangrijk aspect van CQRS is de mogelijkheid om verschillende gegevensmodellen voor lezen en schrijven te gebruiken:
- Schrijfmodel: Geoptimaliseerd voor transactionele consistentie en complexe bedrijfsregels (bijvoorbeeld een genormaliseerde SQL-database).
- Leesmodel: Geoptimaliseerd voor queries en weergave (bijvoorbeeld een gedenormaliseerde SQL-view, een NoSQL-documentopslag of zelfs een cache in het geheugen).
Door deze scheiding kun je voor elk doel de beste opslagtechnologie kiezen.
Voordelen van CQRS
CQRS invoeren kan verschillende voordelen opleveren:
- Schaalbaarheid: Lees- en schrijfwerklasten kunnen onafhankelijk van elkaar worden geschaald.
- Prestaties: Leesmodellen kunnen sterk worden geoptimaliseerd voor specifieke querypatronen.
- Flexibiliteit: Lees- en schrijfmodellen kunnen eenvoudiger afzonderlijk worden ontwikkeld.
- Complexiteit: Het helpt complexe domeinen te beheren door verantwoordelijkheden te isoleren.
Wanneer gebruik je CQRS?
CQRS is niet geschikt voor elk project. Het is vooral nuttig voor:
- Applicaties met complexe bedrijfslogica.
- Systemen met een hoge verhouding tussen lezen en schrijven of verschillende schaalbaarheidsbehoeften.
- Situaties waarin verschillende teams aan lees- en schrijffunctionaliteit werken.
- Situaties waarin je de leesprestaties aanzienlijk moet optimaliseren.
Voor eenvoudigere applicaties is een traditionele CRUD-aanpak vaak voldoende.
Uitdagingen van CQRS
CQRS is krachtig, maar brengt ook enkele uitdagingen met zich mee:
- Toegenomen complexiteit: Meer classes, meer bewegende onderdelen en een mogelijke uiteindelijke consistentie.
- Leercurve: Het is een andere manier om over applicatiearchitectuur na te denken.
- Gegevenssynchronisatie: Lees- en schrijfmodellen synchroon houden kan extra inspanning vereisen (bijvoorbeeld met event sourcing).
Voordat je CQRS implementeert, is een zorgvuldige afweging nodig.
Controleer je begrip
Welke van de volgende opties is een belangrijk voordeel van het CQRS-patroon?
Samenvatting: overzicht van CQRS
In deze les hebben we het patroon Command Query Responsibility Segregation (CQRS) onderzocht.
- We hebben geleerd over Commands (intentie om te wijzigen) en Queries (verzoek om gegevens).
- We hebben gezien hoe Command Handlers en Query Handlers deze verwerken.
- We hebben besproken wat het voordeel is van afzonderlijke gegevensmodellen voor lezen en schrijven.
- Tot slot hebben we de belangrijkste voordelen behandeld, zoals schaalbaarheid en prestaties, evenals de toegenomen complexiteit die CQRS kan introduceren.
CQRS is een krachtig hulpmiddel voor complexe systemen met hoge prestaties!
Leer TypeScript met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 20
- Lessen
- 76
Veelgestelde vragen
Is de les “Overzicht van het CQRS-patroon” gratis?
Ja — de volledige tekst van “Overzicht van het CQRS-patroon” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Enterprise-backend-API's met NestJS wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Enterprise-backend-API's met NestJS bevat in totaal 3 lessen.
Wat leer ik in “Overzicht van het CQRS-patroon”?
Leer meer over het Command Query Responsibility Segregation-patroon (CQRS) en hoe dit de schaalbaarheid en prestaties kan verbeteren. Je oefent met Enterprise-backend-API's met NestJS door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Enterprise-backend-API's met NestJS te beginnen?
Ervaring vooraf is niet nodig. Enterprise-backend-API's met NestJS op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 3.
Hoe lang duurt de les “Overzicht van het CQRS-patroon”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Enterprise-backend-API's met NestJS?
Ja. Elke les over Enterprise-backend-API's met NestJS bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Monorepo versus microservices
- Overzicht van het CQRS-patroon
- Event-driven architectuur