Geschreven door Joost Saanen op 15-9-2022
Bij Kabisa hebben we gildes – een groep medewerkers die geïnteresseerd zijn in een specifieke techniek of stroming in de IT. Gildes zijn een leuk initiatief om op een ongedwongen en informele manier te leren over een bepaald onderwerp. Als Kabisaan ben je lid van één of meerdere gildes en wordt er regelmatig wat georganiseerd. Denk hierbij aan het uitnodigen van een externe spreker die een talk geeft over een bepaald onderwerp of het houden (of geven) van workshops.
Onlangs heeft ons Architecture Guild deelgenomen aan een workshop over DDD (Domain Driven Design). De workshop werd verzorgd door Marc Evers en Rob Westgeest van het bedrijf Quality Without A Name. DDD is een andere manier van het maken van software. Je zorgt ervoor dat je het probleem van een klant écht doorgrondt.
Deze eendaagse workshop was een perfecte manier voor iedereen om de basis te leren van DDD en bekend te raken met de bijbehorende terminologie.
De workshop
De dag begon met een uitleg over wat Domain Driven Design is. Hierna gingen we in groepen aan de slag met Event Storming.
Event Storming is een workshop-gebaseerde methode om snel uit te vinden wat er gebeurt in het domein van software. De techniek brengt alle betrokkenen in het project samen, om complexe bedrijfsdomeinen te verkennen en van elkaar te leren. Dit zijn zowel softwareontwikkelaars als niet-technische gebruikers. Op een grote muur ging men in een aantal groepen flink in de weer met post-its.
Vervolgens werden de modellen verfijnd met users, external systems, commando’s en read models.
Na deze sessie werd er meer gefocust op software architectuur en detailontwerp. Hoe zit het met bepaalde onderdelen van de Event Storm? Kunnen we de subdomeinen en Bounded Contexts bepalen? Het resultaat van de Event Storm werd als basis genomen om te werken aan het ontdekken van zgn. Aggregates. Dit zijn belangrijke concepten binnen een domein, die later ook in de code terug zullen komen.
Waarom DDD?
Elk softwaresysteem begint doorgaans overzichtelijk, maar vroeg of laat groeit het voorbij wat één team kan behappen. Organisaties zoeken naar manieren om vat te krijgen op die complexiteit. Dit door bijvoorbeeld het werk en de verantwoordelijkheid over verschillende teams te verdelen. Dit is een lastig vraagstuk dat raakt aan architectuur en aan de dynamiek van het probleemdomein.
Als er ingezoomd wordt op systemen, wordt vaak code zichtbaar die in termen van technische details spreekt en (business) logica, technische details en frameworks die door elkaar heen lopen. Dit maakt het lastig om de intentie van de code snel te doorgronden - waarom is deze code hier? En wat betekent dat vanuit het business perspectief?
Domain Driven Design is een verzameling patronen die het probleemdomein en de domeintaal centraal stellen, van hoog-over analyse en architectuur, tot design en code.
De patronen helpen bij het grip krijgen op de dynamiek van complexe systemen. En bij het vinden van een opdeling binnen de trade-offs die er zijn en bij het uitwerken van domeinconcepten tot werkende, sprekende code.
Meer weten?
Klinkt dit een beetje vaag? Houd onze website in de gaten. Grote kans dat we binnenkort nog een keer een DDD Workshop organiseren. Omdat onze passie zit in kennisdeling, zijn deze initiatieven vaak publiek toegankelijk. Wil je deelnemen aan onze Kabisa-only workshops? Neem dan ook contact met op ons op. We zoeken namelijk ook nog nieuwe collega’s.
Vragen?
Heb je vragen naar aanleiding van dit artikel? Neem gerust contact met ons op!
(of stuur een bericht)+31 495 430 798
Joost Saanenstuur bericht