In een vorige blog heb ik Microservices in de context van Domain Driven Design (hierna DDD) geplaatst. DDD neemt taal als uitgangspunt om domeinen te definiëren voor dingen die bij elkaar horen. Het helpt daarom bij het afbakenen van je Microservices. Het helpt ook om te begrijpen waarom hergebruik vaak niet lukt. En hoe event sourcing kan bijdragen om het wel weer te laten lukken.
Laat ik trouwens vooraf een bekentenis doen: ik heb lange tijd ook, bijna heilig, in hergebruik geloofd. Bij de Rabobank, rond de eeuwwisseling, heb ik aan de wieg gestaan van het “Componenten centrum”. Doel: hergebruik stimuleren door een marktplaats te organiseren rond software componenten die elders ook ingezet kunnen worden. Het was succesvol, vooral voor relatief kleine, technische componenten. Uiteindelijk opgeheven, omdat we de toegevoegde waarde onvoldoende duidelijk konden maken.
Hergebruik leidt, onwillekeurig, ook tot een probleem dat ik in de ‘bounded context’ blog aan de orde heb gesteld: als een component wordt ingezet in een andere context dan waarvoor de component oorspronkelijk was gemaakt, leidt dat tot problemen. De betekenis in de ene component, het gebruikte wereldbeeld, kan afwijken van de andere component. Als de component wordt aangepast om óók in de nieuwe omgeving te kunnen werken, maakt het dat doorgaans alleen maar erger: de kans neemt toe dat betekenissen door elkaar worden gehaald …
Essentieel van hergebruik is het hergebruik van de informatie zelf, dus zonder de software de de informatie beheerd. Bijvoorbeeld: als je ergens een verhuizing meldt, zou je zeker willen zijn dat alle correspondentie die je van die organisatie ontvangt daarna op het goede adres ontvangt. Een recht toe recht aan aanpak om dat te bereiken (en dus mét hergebruik van de software) is een “Relatie” service waarbij iedere software component die een adres nodig heeft op dat moment het adres op gaat halen. Hiermee wordt zo’n centrale component al snel een bottleneck, en bovendien een “single point of failure”.
Een alternatief voor zo’n “harde” vorm van hergebruik is hergebruik op basis van “event sourcing”: je laat de componenten die verhuizingen kunnen registreren deze gebeurtenissen als een event publiceren. Iedereen, die iets met adressen ‘moet’, kán dan ook kiezen om de adressen niet telkens op te halen maar zich te abonneren op de gebeurtenissen en een eigen adressenbestand op te bouwen. De juiste informatie kan, als de gebeurtenissen worden bewaard, altijd weer gereconstrueerd worden. De gebeurtenis is gebeurd en veranderd daarom nooit. Bovendien biedt het de mogelijkheid een “eigen wereldbeeld” op te bouwen. Als voor een domein alleen het correspondentie adres van belang is, kun je je in beperken tot correspondentie adressen, zelfs zonder dat als zodanig aan te merken. In zo’n domein is een adres een enkelvoudig begrip, zoals we ook maar 1 woord hebben voor sneeuw. (Eskimo’s hebben verschillende woorden voor vallende sneeuw, reeds gevallen sneeuw, opgevroren sneeuw, natte sneeuw, door de wind opgewaaide sneeuw). Als een begrip vanuit een domein wordt overgenomen in een ander domein, moet er een “vertaling” plaats vinden. De “tolk” component, de component die de vertaling verzorgt, moet natuurlijk de taal van beide domeinen kennen.
Naast het voordeel dat betekenis veel preciezer kan worden gehanteerd heeft de “event sourcing” aanpak nóg een voordeel, dat ook heel belangrijk is in de context van Microservices: resilience, of te wel veerkracht en robuustheid. Door het gebruik van de event sourcing wordt de koppeling tussen de componenten aanmerkelijker kleiner. Als een centrale Relatie component wordt gebruikt, en als die niet beschikbaar is, kan er niet meer verzonden worden. Met het gebruik van events is er altijd een redelijk actueel adresbestand beschikbaar. Als de Relatiecomponent even uit de lucht kan het zijn dat je een verhuizing hebt gemist, maar dat wordt weer opgelost als die wel weer beschikbaar is.
