Event Storming wordt vaak geassocieerd met greenfield-projecten: je begint met een schone lei en modelleert je domein van scratch. Maar de grootste waarde van Event Storming zit juist in brownfield-situaties - bestaande systemen waar niemand meer het volledige plaatje heeft. Hier leggen we uit hoe je dat aanpakt.
Waarom Event Storming juist bij legacy werkt
Legacy systemen hebben een gemeenschappelijk probleem: de kennis zit verspreid. De oorspronkelijke architect is vertrokken, de documentatie is verouderd, en elk teamlid kent een ander stuk van het systeem. Event Storming brengt die gefragmenteerde kennis samen op één muur.
Het werkt omdat je niet begint bij de code of de database, maar bij wat er gebeurt in het business domein. Domeinexperts, developers, testers - iedereen plakt oranje sticky notes met domain events: "Order geplaatst", "Betaling ontvangen", "Voorraad gereserveerd". De technische implementatie is even irrelevant.
Stap 1: Big Picture sessie
Begin met een Big Picture Event Storming. Nodig iedereen uit die kennis heeft van het systeem en het business domein - dat zijn vaak meer mensen dan je denkt.
Geef één instructie: "Schrijf op oranje sticky notes de belangrijke dingen die in het systeem gebeuren, in verleden tijd." Geen regels over volgorde of volledigheid. Laat de chaos even bestaan.
Na twintig minuten heb je een muur vol events. Nu begint het echte werk: ordenen op tijdlijn. Dit is het moment waarop verborgen kennis naar boven komt. "Wacht, gebeurt stap X echt vóór stap Y?" "Wie triggert dit event eigenlijk?" Hotspots - plekken waar discussie ontstaat of kennis ontbreekt - markeer je met roze sticky notes.
Stap 2: Identificeer de bounded contexts
In een legacy systeem zijn de grenzen tussen domeinen vaak vervaagd. Een monoliet doet alles, en de database is een gedeelde brei van tabellen die overal vandaan benaderd worden.
Zoek op je Event Storming-muur naar natuurlijke clusters van events. Waar zitten de samenhangende groepen? Waar zitten de pivotal events - de momenten waarop verantwoordelijkheid verschuift van het ene domein naar het andere?
Deze clusters zijn je kandidaat-bounded contexts. Ze vertellen je waar de logische grenzen zitten die in de huidige codebase waarschijnlijk niet gerespecteerd worden.
Stap 3: Map de huidige realiteit
Nu wordt het confronterend. Leg de gevonden bounded contexts naast de daadwerkelijke code-structuur. Waar lopen de grenzen in de code? Waar wijken ze af van de domein-grenzen?
Maak een Context Map: welke bounded contexts bestaan er (impliciet of expliciet), hoe communiceren ze, en waar zitten de pijnpunten? Typische patronen die je tegenkomt in legacy:
- Shared Kernel waar het geen shared kernel zou moeten zijn - gedeelde database tabellen die eigenlijk bij één context horen
- Big Ball of Mud - een deel van het systeem waar geen structuur meer in te herkennen is
- Conformist relaties - teams die afhankelijk zijn van een ander systeem zonder enige invloed op het contract
Stap 4: Kies je gevechten
Je gaat niet het hele legacy systeem in één keer herstructureren. Dat mislukt altijd. Gebruik je Event Storming-resultaten om strategische keuzes te maken:
- Welke bounded context levert de meeste waarde op als je die isoleert?
- Waar zit de meeste veranderdruk - het deel van het systeem waar de business de meeste wijzigingen wil?
- Waar zit het meeste risico - het deel dat de meeste incidenten veroorzaakt?
De intersectie van hoge veranderdruk en hoog risico is waar je begint. Isoleer die bounded context, definieer een duidelijke interface, en begin met het Strangler Fig Pattern: bouw het nieuwe ernaast en migreer geleidelijk.
Praktische tips
- Beperk sessies tot drie uur. Langer is niet productief.
- Meng rollen. De waarde zit in het samenbrengen van verschillende perspectieven. Alleen developers in de ruimte levert een technisch model op, geen domeinmodel.
- Fotografeer alles. Sticky notes vallen van muren. Maak foto's na elke sessie.
- Verwacht oncomfortabele momenten. Event Storming bij legacy legt bloot waar kennis ontbreekt en waar aannames niet kloppen. Dat is precies de bedoeling.
- Itereer. Eén sessie is niet genoeg. Plan een reeks van sessies met toenemend detail.
Bij NForza zetten we Event Storming regelmatig in bij organisaties die worstelen met legacy systemen. Het is een van de meest effectieve technieken die we kennen om gedeeld begrip te creëren en een pad naar modernisering uit te stippelen.