Ontkoppeling in softwarearchitectuur verplaatst complexiteit

Wat gebeurt er als iemand op de knop 'Bestelling plaatsen' klikt?

Voor de eindgebruiker is het vrij simpel. Het is een muisklik. Maar in een groot systeem kan er veel meer achter die knop schuilgaan. We moeten de bestelling opslaan, de betaling registreren, de creditcard van de klant belasten, voorraad reserveren, een bevestigingsmail versturen en misschien loyaliteitspunten registreren. Er kunnen ook analyses, aanbevelingen of andere processen zijn die op de bestelling reageren.

Omdat er zoveel gebeurt, kan er ook veel misgaan.

Er wordt ons vaak verteld dat ontkoppeling geweldig is. Gebruik abstracties. Gebruik dependency injection. Vervang directe aanroepen door berichten en wachtrijen. Gebruik publish-subscribe en een event-driven architectuur.

Al die dingen kunnen nuttig zijn, maar het zijn geen doelen op zich. En belangrijker nog, ze zijn niet gratis.

Elke stap die je weghaalt van een methodeaanroep in het geheugen voegt een nieuwe vorm van complexiteit en nieuwe kosten toe. Je wint er misschien wel onafhankelijke implementeerbaarheid, uitbreidbaarheid, schaalbaarheid of andere beschikbaarheidskenmerken mee. Maar je introduceert ook iets nieuws dat je nu moet begrijpen, bedienen en debuggen.