Zonder Domain-Driven Design geen microservices

Als je de ideale grootte (of granulariteit) van microservices wilt bepalen, dan kun je eigenlijk niet om Domain-Driven-Design (DDD) heen. Deze manier van werken (of eigenlijk communiceren) stelt functionaliteit centraal en dwingt de engineer en de domeinexpert om echt samen te werken en gemeenschappelijke modellen te creëren.

Vaak worden ongemerkt dezelfde termen voor verschillende dingen gebruikt, en omgekeerd. Het is de kunst om echt naar elkaar te luisteren, de nuances te begrijpen en vooral de context waarin termen eenduidig zijn te herkennen. Binnen die context gebruikt DDD de ubiqitious language waarin iedere term helder gedefinieerd is.

Ongewenste functiekoppeling

Neem bijvoorbeeld de term ‘persoon’; deze kan in heel veel contexten worden gebruikt. In een architectuur maakt het nogal wat uit of een persoon een leverancier, een prospect of een werknemer is. Een werknemer wil je kunnen promoveren, ziek en beter kunnen melden. Aan een leverancier kennen we totaal ander gedrag aan toe. Al dit verschillende gedrag achter een enkele microservice plaatsen, leidt tot ongewenste functionele koppeling.

Ook voor de service interacties is het essentieel om de context helder te hebben. Stel: de microservice die je gebruikt voor een werknemer-persoon moet worden gelinkt aan het salarissysteem. Wanneer het salarissysteem zich conformeert aan de werknemer-persoon service wordt een transformator op de korte termijn voorkomen. Echter, een wijziging aan het model van de werknemer-persoon service betekent een rimpel effect op het salarissysteem. Wanneer het daar stopt is het te overzien, maar als het salarissysteem diezelfde berichten weer stuurt naar een service kan er snel een olievlek ontstaan. DDD helpt het inzicht krijgen in waar een transformator functioneel nuttig is.

Succes zit in design

Een belangrijke beloftes van microservices is een snellere time-to-market doordat ze flexibeler zijn. Hoe gaan we de service maken, met welk framework, met welke taal en welke tools? De techniek echter slechts een middel, het succes zit in het strategisch design.

Een intern geweldig ontworpen autonome applicatie met een ambigue interface of ondoordachte interacties is wel micro en lijkt technisch op een service. Maar levert het ook daadwerkelijk een dienst? DDD helpt ons de service centraal te stellen in plaats van de techniek. Daarmee zijn we in staat de beoogde voordelen te halen en dat is wat de business van ons verwacht.