DDD Meetup over software design heuristics
Gisteren was er een DDDBelgium meetup over software design heuristics door Mathias Verraes. Ik ging daar samen met collega Niels naartoe, en hier volgt een klein verslag van wat we geleerd hebben.
Workshop setup.
De workshop was in echte DDD-stijl zonder digitale hulpmiddelen en we maakten gebruik van pen en papier, zodat er verder geen afleiding was. We startten met ons op te delen in groepjes van 2. Mathias stelde ons een vraagstuk om eerst vanuit het buikgevoel en daarna in meer detail te bespreken hoe een systeem een bepaalde boodschap naar een ander systeem kan sturen.
Het exacte vraagstuk was als volgt:
Er bestaat een systeem (A) dat een prijs berekent tot 4 cijfers na de komma, en een systeem B dat die prijs wil ontvangen. Hoeveel informatie bevat de prijs die je doorstuurt naar systeem B, 4 of 2 cijfers. Verschillende mensen in het publiek hadden op buikgevoel voor 2 cijfers gekozen, en een ander deel had voor 4 cijfers gekozen.
Nadat we ons buikgevoel kenbaar hadden gemaakt, moesten we met onze duo's verder bespreken waarom we die keuze gemaakt hadden. Daarna destilleerden we dat naar meer generieke patronen die ook op andere problemen toepasbaar zijn.
De argumenten voor de twee mogelijke opties kwamen al snel naar boven:
Pro 2 cijfers
- Verbergen van informatie
- Volgen van internationale standaarden
- Grootte van het bericht
- Eigendom van de informatie (en business-rules zoals afronding) niet dupliceren
Pro 4 cijfers
- Alle mogelijke informatie meesturen
- Een reeds bestaand contract/conventie volgen
Er was natuurlijk ook een duo die nog een stap verder ging en voorstelde om de twee versies tegelijk door te sturen, daar kwam ook een heuristic uit naar voor: Ben je zeker dat de voorgestelde binaire keuzes ook echt de enige opties zijn?
Conclusie
Deze techniek zorgde er voor dat we duidelijker kunnen argumenteren waarom je buikgevoel voor een bepaalde oplossing gaat en hoe je daarmee om moet gaan. Dit zorgt er voor dat je op een meer analytische manier kan bekijken waarom er verschillende meningen zijn om een probleem op te lossen.
Mathias merkte wel op dat deze manier van een probleem bekijken veel tijd in beslag kan nemen. Maar dat het herkennen van deze heuristische patronen kan helpen om een probleem langs meerde kanten te bekijken en zo tot een meer complete oplossing te komen.
Sowieso was het wel interessante workshop, bedankt aan spilberg om de meetup te hosten.
The benefit of prefixing my software design heuristics session with "DIY" is that I can sit back and let the audience do the work :-) @DDDBE pic.twitter.com/TTZiJorl7V
— Mathias Verraes (@mathiasverraes) January 21, 2020
