Dennis Adriaansen Blog Eventstorming voor webapplicaties: Hoe je grote aanpassingen kunt structureren
15 Jun 2017
Dennis Adriaansen

Eventstorming voor webapplicaties: Hoe je grote aanpassingen kunt structureren

Ingrijpende wijzigingen in een webapplicatie vereisen overzicht. Zodra er cruciale wijzigingen moeten worden doorgevoerd bestaat de kans dat er fouten optreden of dat delen niet meer correct functioneren.

Om dit te voorkomen is er een techniek die ingezet kan worden. Hierdoor wordt communiceren tussen verschillende teams specifieker,  makkelijker en zorgt het voor behoud van overzicht en kwaliteit. Ook na ingrijpende aanpassingen.

Het overzicht bewaren tijdens ingrijpend veranderingen in webapplicaties

In dit artikel beschrijf ik een techniek die zorgt dat jij en jouw team het overzicht behouden tijdens ingrijpende wijzigingen.

Wat is Domain Driven Design en wat Eventstoring

Domain driven design is een ontwikkelproces waarbij een specifiek domein centraal staat. Het wordt domain heeft in deze context niets te maken met een domeinnaam als google.nl. Een domein in DDD (Domain Driven Design) kan gezien worden als de primaire basis van een applicatie. Deze basis bevat alle kennis en filosofie van het betreffend project.

Wat is Eventstorming

Bij eventstorming wordt elk domein verdeeld in verschillende Domain Models. Een Domein Model verwijst naar een specifiek probleem, de context waarin dit probleem zich voordoet en gevolgen ervan. Elk Domain Model heeft zijn eigen oplossing (Model) 

Bij het in kaart brengen van het Domain, de Domain Models en de Models wordt voor iedereen binnen een project duidelijk wat er moet gebeuren onder welke voorwaarden. Iedereen, zowel technische als niet technische medewerkers weten welke problemen zich voor doen en welke maatregelen er getroffen moeten worden om de problemen op te lossen. 

Tijdens het bepalen van het Domain en Domain Models wordt er niet gesproken over technische implementaties. Iedereen binnen het project moet volledig op de hoogte zijn van elk element binnen een domein. Alleen de ontwikkelaars hoeven op te hoogte te zijn van de implementatie. Met het Domain Model in gedachte weten de ontwikkelaars welk hoger doel moet worden behaald en dus is de kans groter de het probleem op een effectieve wijze wordt getackeld. 

Terminologie:

  • Domain
    Een specifiek onderdeel binnen een webapplicatie die verantwoordelijk is voor geïsoleerd gedeelte van het systeem. 
  • Domain model
    Een probleem binnen een domain
  • Model
    Oplossing / implementatie om het probleem te verhelpen. 

Transparantie in kosten en gevolgen van wijzigingen binnen grote webapplicaties

Bij bestaande projecten zijn bepaalde componenten / onderdelen vaak verantwoordelijk voor verschillende functionaliteiten. Een component kan op verschillende plekken worden gebruikt waardoor wijzigingen veel gevolgen hebben. Wanneer er geen overzicht is van de componenten en zijn verantwoordelijkheden zal de ontwikkelaar niet de gepaste oplossing implementeren waardoor ontwikkeltijd uitloopt en niemand accuraat kan inschatten hoeveel tijd dit in beslag gaat nemen of heeft genomen. 

- Wanneer er geen tijdschatting gemaakt kan worden blijft het onbekend of een project rendabel wordt, is en blijft. 
- Wanneer eventstorming wordt toegepast om het gehele domein in kaart te brengen worden er verschillende voordelen zichtbaar. 

  • Tijdschattingen zijn accurater omdat problemen op voor hand zijn getackeld
  • Aanpassingen kunnen worden geprioriteerd d.m.v de kosten op te wegen tegen de baten 
  • Communicatie gebeurd accurater omdat een groter aantal medewerkers in een breder werkveld actief zijn.

Zodra het Domain bekend is kan er gekeken worden van de specifieke Domain Models zijn. Tijdens de laatste vergaderingen is gebleken dat een bepaald onderdeel binnen de webapplicatie niet correct functioneert. Het onderdeel en zijn probleem worden gebundeld in een Domain Model. Het probleem wordt hierin gedocumenteerd op een wijze dat zowel de ontwikkelaars als de leidinggevende snappen wat er moet gebeuren. 

Hoe zorg je voor een compleet overzicht?

Het gehele doel van eventstorming is om voor zowel technische als niet technische mensen inzichtelijk te maken wat er gebeurd binnen een domain. Het inzichtelijk maken gebeurd door middel van de juiste mensen te verzamelen die de juiste vragen stellen. Een evenstorming sessie kan zo lang duren als nodig. Bij een gemiddeld complex project zal het enkele uren duren. Daarnaast is het mogelijk, en wellicht een goed idee, om verschillende sessies in te lassen. 

Elk domain kan opgedeeld worden in subdomains. Wanneer dit gebeurd zullen de verschillende subdomains meer specifiek behandeld worden. Uiteraard zorgt dit ervoor dat de gehele sessie op een hoger niveau wordt gehouden en dat problemen nog specifieker benaderd kunnen worden. 

Hoe ziet een evenstorming sessie er uit? 

  1. Samenzitten met mensen die vragen hebben en mensen die de antwoorden weten 
  2. Het Domain Model defineren en uitschrijven
  3. Alle obstakels, gevolgen en benodigdheden documenteren
  4. Proces inclusief alle stappen verzamelen in een roadmap

Wat heb ik nodig voor een evenstorming sessie?

  • Een rustige ruimte met genoeg ruimte voor het gehele team dat betrokken is binnen het domain. 
  • Een oppervlakte waar notities geplaatst kunnen worden. Denk aan een whiteboard of MÅLA (klik) Het is aan te raden om te werken met post-its aangezien deze snel van positie gewisseld kunnen worden. 
  • Pen of potlood waarmee geschreven kan worden

Vragen over eventstorming of benieuwd of een sessie jouw bedrijf verder kan helpen? 

Stuur een bericht via LinkedIn of mail mij direct