Blog · 27 februari 2025
EventStorming bij Aardling
Hoe we EventStorming aanleren bij onze klanten

EventStorming bij Aardling
EventStorming is een erg populaire modelleertechniek, voor het eerst geïntroduceerd door Alberto Brandolini. Bij Aardling gebruiken we een wat andere aanpak dan de "Brandolini"-stijl van EventStorming. Laat me onze stijl uitleggen, en waarom we die verkiezen.
Deze blog is geen tutorial, maar eerder een uitleg van hoe wij EventStorming toepassen. Bekijk onze videoreeks over modelleren voor een diepgaandere blik op hoe we modelleren.
Om te beginnen: dit zijn de basisbouwstenen die we gebruiken in EventStorming:
💡 Tip: whiteboardtools zoals Miro of Lucid laten je een stapel sticky notes gebruiken, waardoor deelnemers makkelijker nieuwe kunnen toevoegen.
Domain events
👉 Een domain event is iets dat relevant is voor het domein, uitgedrukt in de verleden tijd. Events stellen feiten voor, dingen die gebeurd zijn. Bijvoorbeeld: "Factuur werd betaald", "Abonnement vernieuwd".
Wanneer we beginnen te modelleren, gebruiken we events om de probleemruimte voor te stellen. Eenmaal in een workshop met domeinexperts visualiseren we de events om een samenhangend verhaal te vertellen. Modelleren begint altijd met veel onzekerheid. Hou vol, en wat al snel ontstaat, is een rijk, gedeeld begrip van de probleemruimte.
Zodra we tevreden zijn met wat we geleerd hebben en het verder willen verkennen, voegen we commands en constraints toe.
Commands en constraints toevoegen
👉 Commands, soms acties genoemd, drukken een intentie uit om iets te doen. Uitgedrukt in de gebiedende wijs. Een gebruiker of een systeem wil iets doen. Voorbeelden: "Betaal factuur", "Vernieuw abonnement".
👉 Constraints drukken een beslissing, een voorwaarde of om het even wat uit dat de uitkomst van een command of een event beïnvloedt.
Om te beginnen ziet onze EventStorm er ongeveer zo uit. Oranje stickies stellen hier de events voor.
Laten we nu het volgende patroon introduceren:
Eerst leggen we de actie (command) vast die iemand, of iets, wil triggeren. Maar om verder te kunnen, moeten we rekening houden met de constraints van de business. Als die voldaan zijn, wordt een beslissing genomen (event).
Bijvoorbeeld: reserveer tafel → tafel moet beschikbaar zijn → tafel gereserveerd
Natuurlijk kunnen er meerdere constraints zijn, die we zo voorstellen:
Of, als de volgorde van de constraints er niet toe doet, zo:
Wanneer we denken dat er geen constraints zijn tussen de trigger en de uitkomst, maken we dat expliciet door de Always-constraint te introduceren. Documenteer dus zo dat het gesprek gevoerd is en er geen constraints gevonden zijn:
Gesprekken strijken misverstanden glad. In modelleersessies heb je vaak gesprekken als deze:
"Altijd, als dit gebeurt, dan gebeurt dat …"
"Is dat echt altijd wat er gebeurt?"
"Ja"
"Oh, en wat als dit gebeurt, en dan dat gebeurt…?"
"Ah, je hebt gelijk, in dat geval zou het eigenlijk moeten mislukken"
We hebben gemerkt dat de always-constraint weglaten vaak het hele gesprek wegneemt, met ontbrekende constraints als gevolg.
Een laatste patroon dat je kunt overwegen toe te voegen, is dit:
-
event → constraint → event
of
-
event → constraint → command
De definitie van een constraint zegt dat het om het even wat is dat de uitkomst van een trigger beïnvloedt. Een trigger kan ook een event zijn, dus je kunt voorbeelden als deze hebben:
Wat gebeurt er als de constraint faalt? In dat geval modelleren we beide paden:
Dit is een overzicht op heel hoog niveau van ons EventStorming-proces, maar het bevat de fundamentele bouwstenen die je nodig hebt om te beginnen. Probeer het uit in je volgende sessie en kijk hoe het gaat. De beste manier om je EventStorming-vaardigheden te verbeteren, is oefenen en wat je geleerd hebt meenemen naar je volgende sessie.
Een laatste tip: voeg je eigen visuele taal toe om dingen uit te drukken die belangrijk zijn in jouw context. Misschien wil je bijvoorbeeld verschillende kleuren gebruiken voor de verschillende systemen die het event uitsturen, of een andere kleur voor summary events.
Denk er niet te lang over na, maar ga ervoor.
Heb je vragen of feedback, dan vind je me op LinkedIn/BlueSky, of je kunt ons schrijven.