Laatst legde ik een aantal kernconcepten van Domain Driven Design (DDD) uit. Een van de ontwikkelaars vroeg me naar CQRS. Ik heb gemerkt dat veel ontwikkelaars beginnen met CQRS om het lees- en schrijfmodel te scheiden bij het implementeren van DDD.
In dit blog duik ik er wat dieper in: wat is CQRS? En: wat zijn de voordelen en het gebruik van CQRS met DDD?
Wat is CQRS?
Laten we beginnen met de basis. CQRS staat voor Command Query Responsibility Segregation.
Segregatie (of opsplitsing) van verantwoordelijkheid (wie doet wat) van acties die de status veranderen of wijzigen en acties die de status niet veranderen. Acties die de status kunnen veranderen, noemen we Commando's en niet-veranderende acties noemen we Query.
CQRS gaat dus over het scheiden van wat de status verandert en wat niet.
Â
CQRS als architectuur
CQRS is wat we een architectuurpattern noemen en is niet beperkt tot een specifieke plaats in de software. De scheiding tussen lezen en schrijven kan op vele plaatsen voorkomen, zoals databases, code of hele systemen. CQRS is niet per se een DDD vereiste, maar CQRS kan goed gebruikt worden in combinatie met DDD.
Waarom hebben we CQRS nodig?
In de meeste toepassingen is de toegang tot gegevens bedoeld om de toestand te lezen, niet om de toestand te veranderen. Bijvoorbeeld: in een webshop blader je (lees je) door veel meer items dan dat je toevoegt (schrijf je) aan je winkelmandje. Het optimaliserende effect van CQRS (veel lezen scheiden van soms schrijven) in de applicatie kan prestatievoordelen en kostenbesparende effecten hebben.
Â
Eventual Consistency
De basis onder deze scheiding van lezen en schrijven is uiteindelijke consistentie.
Eventual consistency betekent dat een toestandsverandering niet onmiddellijk wordt geprojecteerd. Er is een vertraging. Maar de toestandsverandering zal uiteindelijk correct worden weergegeven.
Als we teruggaan naar het voorbeeld van de webshop: als we naar een specifiek product kijken, laten we zeggen gele badeendjes, dan zie je naast de afbeelding van het badeendje het aantal bijv. 17 badeendjes dat op voorraad is. Maar dat aantal is misschien niet 100% accuraat, omdat er een klein tijdsgat zit tussen het moment dat de gegevens van de afbeelding en het aantal op voorraad uit de database worden gelezen en het moment dat het op je scherm wordt weergegeven. Tijdens dat tijdsgat kan het aantal artikelen op voorraad zijn veranderd. Misschien heeft iemand een badeend teruggebracht, dus het aantal kan 18 zijn. Of iemand heeft net 3 badeendjes gekocht, wat betekent dat het werkelijke aantal badeendjes in voorraad 14 is.
CQRS maakt gebruik van dit fenomeen. We hoeven niet altijd 100% correcte gegevens te zien (lezen). In feite maakt het in de meeste gevallen helemaal niets uit, omdat de gegevens nauwkeurig genoeg zijn om te werken. De enige keer dat gegevens nauwkeurig moeten zijn, is wanneer iemand de status (schrijven) van het systeem probeert te veranderen door 8 badeendjes in zijn winkelmandje te stoppen.
Dus, door lezen te scheiden van schrijven, commando's van queries, kunnen we de efficiëntie verhogen door gebruik te maken van de aard van eventual consistency.
Wil je meer weten over DDD en CQRS? Heb je hulp nodig bij het implementeren van deze zaken? Schrijf je dan in voor een van onze DDD-trainingssessies.
Comments