CQRS en Event Sourcing in applicatie-architecturen
29 mei 2018 | Nieuws | Door: AMIS Conclusion
Deel
In deze kennissessie gaan we CQRS, Bounded Context en Event Sourcing bespreken. We bepalen toepassingscriteria en eisen aan architectuur, ontwerp en implementatie. De sessie legt de basis voor een Way We Work en bepaalt het kader voor een vervolgsessie op donderdag 21 juni waarin we de tools en technologie voor implementatie van CQRS nader gaan onderzoeken met ontwikkelaars, platformspecialisten en DBAs. Van deelnemers wordt een actieve bijdrage gevraagd in de brainstorm en discussie.
CQRS
CQRS (Command Query Responsibility Segregation) is een architectuurpatroon dat simpelgezegd stelt dat de datastore die data ontvangt en manipulaties verwerkt, niet dezelfde hoeft te zijn als de engine die query’s beantwoordt. Er zijn verschillende redenen – van performance en beschikbaarheid tot schaalbaarheid, security, en (licentie)kosten – waarom je een C-database en een of meerdere Q-bronnen in een architectuur opneemt.
Tijdens de sessie komen de volgende vragen aan bod:
- Wat zijn overwegingen om tot een vorm van CQRS over te gaan?
- Welke praktijkvoorbeelden kennen we?
- Wat zijn uitdagingen die in geval van CQRS moeten worden opgelost?
- Met welke selectiecriteria kiezen we een technische oplossing voor de implementatie van CQRS?
- Welke requirements – functioneel en non-functioneel – zijn mede bepalend voor de oplossing (bijvoorbeeld: hoe “vers” moet de data in de Query-store zijn?
Bounded context
In een microservices architectuur heeft elke microservice zelf de verantwoordelijkheid voor de data (bounded context) die nodig is. Naast de data waarvan de microservice de eigenaar is, omvat de bounded context ook afgeleide data – data waarvan andere microservices eigenaar zijn maar die een wel nodig is om stand-alone te kunnen functioneren. Het bijhouden van deze afgeleiden gegevens is een vorm van CQRS die we ook zullen bespreken.
Event Sourcing
Een ander, verwant patroon is Event Sourcing. In pure vorm beschrijft dit patroon hoe we alle events registreren die wijzigingen van ‘application state’ beschrijven als de single, immutable point of truth van waaruit de huidige state (of de state op een tijdstip in het verleden) kan worden afgeleid. In plaats van een database met een active record dat voor iedere business object de huidige waarheid beschrijft en dat met updates wordt bijgewerkt, gebruiken we een event store waarin alleen inserts van events plaatsvinden. Deze events en deze store kunnen een (Command-)bron zijn om Query-stores vanuit op te bouwen en bij te werken.
Doelgroep
Architecten en in architectuur geïnteresseerden
DEElnemen
Vergeet niet een laptop mee te brengen.
Wil je bij deze kennissessie op 5 juni aanwezig zijn? Stuur dan een mail naar marketing@amis.nl onder vermelding van 'Aanmelding kennissessie CQRS en Event Sourcing in applicatie architecturen'. Aan deelname zijn geen kosten verbonden.
Wij zorgen voor het diner. Heb je dieetwensen? Geef dat dan aan in de mail. Ken je iemand voor wie deze avond ook interessant is? Dan is diegene natuurlijk ook van harte welkom. Laat diegene zich wel even zelf aanmelden in verband met de catering en het totaal aantal beschikbare plekken voor deze sessie.