Technische sessie: Intro to CQRS
•Download as PPTX, PDF•
0 likes•820 views
Command Query Responsibility Segregation Idee: Een methode veranderd de status van een object of geeft een resultaat terug, maar niet beide. Gevolg: je kan een ander model gebruiken voor ‘reads’ (queries) dan voor ‘writes’ (commands)
Recommended
Recommended
More Related Content
Similar to Technische sessie: Intro to CQRS
Similar to Technische sessie: Intro to CQRS (20)
More from ABC-GROEP.BE
More from ABC-GROEP.BE (20)
Technische sessie: Intro to CQRS
- 1. CQRS
- 2. OVERZICHT • Wat is CQRS • Situering • Vervolg
- 3. OVERZICHT • Wat is CQRS
- 4. WAT IS CQRS • Command Query Responsibility Segregation • Idee: Een methode veranderd de status van een object of geeft een resultaat terug, maar niet beide. • Gevolg: je kan een ander model gebruiken voor ‘reads’ (queries) dan voor ‘writes’ (commands)
- 5. TRADITIONEEL: CRUD • Alle acties (lezen en schrijven) gebeuren via hetzelfde model en volgen hetzelfde pad. • Hoofdzaak is het bewaren en opvragen van deze model objecten. • De vraag en noden worden meer complex. • Verschillende views op de data • Meerdere records samenvoegen in 1 weergave (virtuele records) • Validatie bij het bewaren • …
- 6. TRADITIONEEL: CRUD Application DB UIModel Model leest uit database Service biedt informatie aan voor weergave Gebruiker doet wijzigingen Wijziging doorsturen naar model Model voert validatie en logica uit Model update database
- 7. CQRS • Structuur met verschillende weergaven kan snel tot een complex model leiden • Reden: de verschillende weergaven worden vertaalt naar éénzelfde model dat als integratiepunt dient. • CQRS deelt dit op in verschillende modellen voor update en weergave
- 8. Application DB UI Command Model Query model leest uit DB Query service biedt informatie aan voor weergave Gebruiker doet wijzigingen Applicatie stuurt gewijzigde info door naar het command model Command model voert validatie en logica uit Command model update database Query Model
- 9. CQRS • De (in-memory) models kunnen dezelfde database gebruiken • Database is de communicatie tussen beide models • Ze kunnen ook verschillende databases gebruiken • Optimalisatie mogelijk per DB voor de specifieke taken (indexen, views, reporting …) • Nood aan een communicatiemechanisme tussen de models/databases
- 10. OVERZICHT • Wat is CQRS • Situering
- 11. SITUERING • CQRS is GEEN volledige architectuur. • CQRS is WEL een design pattern. • CQRS is toepasbaar op onderdelen van een project waar het nodig is. Niet op het volledige project. • Past zeer goed in het kader van DDD (Domain Driven Design) waarbij CQRS toegepast kan worden op specifieke sub-domeinen (Bounded Context)
- 12. DOMAIN DRIVEN DESIGN • Typisch (ref. CRUD) worden Domain Model en Store model zeer gelijkaardig gehouden om mappings te vereenvoudigen. • Zeker met technologeën zoals EntityFramework • Gevolg: Model wordt complexer dan nodig. • Een zeer eenvoudige view kan door het model zeer complexe queries en logica veroorzaken • Bvb. Een order plaatsen op amazon is 1 klik op de knop, achterliggend een volledige flow • Bvb. data uit meerdere tabellen in 1 view tonen (joins)
- 13. UBIQUITOUS LANGUAGE (UL) • Concept • “Alomtegenwoordige” taal • Verzameling gebruikte vaktermen • Gedeeld door alle betrokken partijen • Verwarring minimaliseren
- 14. UBIQUITOUS LANGUAGE (UL) • Werkwoorden en zelfst. naamwoorden • Sleutel concepten binnen de business logica • Mappen naar technische implementaties • Queries, commands en saga’s
- 15. BOUNDED CONTEXT (BC) • Afgebakend deel van het domein, business logica • Groeit naargelang de kennis van de UL groeit • Één term kan meerdere betekenissen hebben in verschillende BCs
- 16. BOUNDED CONTEXT (BC) • Realiteit: Amazon.com • “Gebruiker” in de login BC • “Klant” in de payment BC • Context is dus belangrijk
- 17. OVERZICHT • Wat is CQRS • Situering • Vervolg
- 18. VERVOLG • Verschillende implementatie mogelijkheden • Basic • Deluxe • Eventsourcing • Verschillende stores (read en write) in sync houden • Maakt CQRS de zaken niet complexer?
Editor's Notes
- Idee: Een vraag stellen mag het antwoord niet wijzigen of het antwoord mag niet beïnvloed worden door de vraag. Typisch: Commands return void Queries declare a return type Before describing the details of CQRS we need to understand the two main driving forces behind it: collaboration and staleness. Collaboration refers to circumstances under which multiple actors will be using/modifying the same set of data – whether or not the intention of the actors is actually to collaborate with each other. There are often rules which indicate which user can perform which kind of modification and modifications that may have been acceptable in one case may not be acceptable in others. We’ll give some examples shortly. Actors can be human like normal users, or automated like software. Staleness refers to the fact that in a collaborative environment, once data has been shown to a user, that same data may have been changed by another actor – it is stale. Almost any system which makes use of a cache is serving stale data – often for performance reasons. What this means is that we cannot entirely trust our users decisions, as they could have been made based on out-of-date information.
- Idee: Een vraag stellen mag het antwoord niet wijzigen of het antwoord mag niet beïnvloed worden door de vraag. Typisch: Commands return void Queries declare a return type
- Idee: Een vraag stellen mag het antwoord niet wijzigen of het antwoord mag niet beïnvloed worden door de vraag. Typisch: Commands return void Queries declare a return type
- Opdelen van modellen tussen lezen en schrijven: Voor veel problemen (zeker in complex domeinen) is het dikwijls veel complexer om hetzelfde model te gebruiken voor commando’s en queries met als gevolg dat beiden niet 100% goed zijn. Nooit optimaal CQRS laat ook toe om meerde read-modellen te hebben. Zo kan je het model optimaliseren naar de view, cfr de virtuele in-memory records
- Als we weggaan van het CRUD principe, kunnen we eenvoudig naar een task-based UI gaan (tasks = commands) Het command model gaat goed samen met eventsourcing: zie vervolg sessie Verschillende models: hoe consistent houden? => gebruik van “Eventual consistency”
- Geen vervanging voor reporting database
- Voorbeeld UL = stijve 2,5 carré in de electriciteit = koperen geleider van 2,5mm doorsnede met een harde kern Ander voorbeeld = niet een “record deleten” maar “bestelling annuleren”
- Voorbeeld UL = stijve 2,5 carré in de electriciteit = koperen geleider van 2,5mm doorsnede met een harde kern Ander voorbeeld = niet een “record deleten” maar “bestelling annuleren” Link vermelden naar commands Saga’s => workflows, user stories, een serie van acties die geen user interventie vragen Vb. een order plaatsen start een bepaalde flow (saga) Stock aanpassen Leverdatum bepalen Leveringsdienst reserveren …
- BCs = login area, buy area Gebruiker verschillende interpretaties binnen een website (aanmelden, koper...) VB: MVC Areas (IntraNet) Area om producten te bestellen (gebruikers zijn klanten) Niet elke werknemer mag producten bestellen => sommige zijn dus geen klanten Area om vragen te stellen aan HR Gebruiker is werknemer De gegevens voor beide gebruikers zijn verschillend en hebben niet noodzakelijk een verband
- BCs = login area, buy area Gebruiker verschillende interpretaties binnen een website (aanmelden, koper...) VB: MVC Areas (IntraNet) Area om producten te bestellen (gebruikers zijn klanten) Niet elke werknemer mag producten bestellen => sommige zijn dus geen klanten Area om vragen te stellen aan HR Gebruiker is werknemer De gegevens voor beide gebruikers zijn verschillend en hebben niet noodzakelijk een verband
- Waar zou ik het willen gebruiken? Een zekere complexiteit Rekening houden met overhead Overkill voor kleine projecten We gaan een antwoord bieden op volgende vragen: Hoe implementeer ik het? Waarom zou ik CQRS gebruiken?