Event Storming

Eventstorming DDD

Onlangs kreeg ik de kans om mee te doen met een brainstorm sessie bij een mooie start-up. Het doel was om samen met twee andere software ontwikkelaars van gedachten te wisselen om te kijken of er ergens aanknopingspunten zouden zijn om verder onderzoek te doen naar een probleem wat een tijdje speelde.

Na wat praten over elementen, services en systemen, heb ik mijn Miro board gedeeld en ben ik gaan modelleren via de Event Storming technieken van –Alberto Brandolini.

zie plaatje1

Het was mooi om te merken dat ik langzaam het event sourcing systeem kon modelleren zonder nauwelijks voorkennis van het systeem te hebben. En ik merkte dat ik gerichte vragen kon stellen die relevant waren voor de ontwikkelaars die wel de ervaring hadden met het systeem.

Samen zoomde we eerst in op het proces via het modelleren met virtual sticky notes, en we zoomde weer uit. Om vervolgens weer in te zomen op de service die hoogst waarschijnlijk het probleem veroorzaakte.

Samen stelde we de juiste vragen, en door het creƫren van visuele modellen wisten we allemaal precies over welke service we spraken. En waar die service zich bevond in het systeem, en op welk punt in de tijd het probleem zich waarschijnlijk voordeed.

Het leverde ook een hoop paarse (hot spot) sticky notes op met vragen, opmerkingen en over welke aannames we deden. En het leverde de twee ontwikkelaars op dat zij gericht verder konden om het probleem op te lossen.

Mij leverde het een gezellige en leerzame ochtend op en veel energie om mij meer bezig te willen houden met samenwerken, visueel modelleren, DDD en architectuur als een software facilitator.

model

Event Storming

Recently I got the chance to join a brainstorming session at a nice start-up. The goal was to exchange thoughts with two other software developers to see if there would be any leads somewhere to further investigate a problem that had been around for a while.

After a bit of talking about elements, services and systems, I shared my Miro board and started modeling using the “Event Storming” techniques of –Alberto Brandolini.

It was nice to notice that I could slowly model the “event sourcing” system without having hardly any prior knowledge of the system. And I found that I could ask targeted questions that were relevant to the developers who did have the experience with the system.

Together, we first zoomed in on the process through modeling with virtual “sticky notes,” and we zoomed out again. Then we zoomed back in on the service that was most likely causing the problem.

Together we asked the right questions, and by creating visual models we all knew exactly what service we were talking about. And where that service was located in the system, and at what point in time the problem likely occurred.

It also produced a lot of purple (hot spot) “sticky notes” with questions, comments, and about what assumptions we were making. And it provided the two developers with a focused way forward to solve the problem.

It was a pleasant and instructive morning for me and it gave me a lot of energy to want to focus more on collaboration, visual modeling, DDD and architecture as a software facilitator.

Translated with www.DeepL.com


  1. plaatje is onherkenbaar gemaakt ↩︎

 Share!

 
comments powered by Disqus