Waarschijnlijk heb je wel eens gehoord van het Dependency Inversion-principe (DIP). Bij veel implementaties betekent DIP zoveel als “zorg ervoor dat je classes afhankelijk zijn op abstracties in plaats van concrete details”. Ports and Adapters-architectuur (ook bekend onder de namen Hexagonal-architectuur of Onion-architectuur) tilt dit naar een hoger niveau. Letterlijk. Want waar mensen die DIP toeppassen dit vooral doen op klasse-niveau, past Ports and Adapters dit toe op de architectuur van een service.

Concreet betekent Ports and Adapters dat de kern van je service, waar de bedrijfslogica zich bevindt autonoom werkt, en enkel via poorten aangeroepen worden door aansturende adapters (ook wel: driving of primary adapters genoemd). Zelf communiceert deze bedrijfslogica ook alleen maar naar buiten via “poorten” naar aangestuurde adapters (ook wel: driven of secondary adapters). Dat betekent dat de bedrijfslogica van je applicatie compleet onwetend is over hoe het aangeroepen wordt of wat het aanroept. De bedrijfslogica weet alleen dat het aangeroepen wordt door “iets”, of dat nu een Android app is, of een console commando.

Bron: https://herbertograca.com/2017/09/14/ports-adapters-architecture/

Oké, maar hoe werkt dit dan in de praktijk? Stel, je wilt notificaties sturen vanuit je applicatie zoals in bovenstaand diagram. Vanuit de Ports and Adapters architectuur schrijf je dan een interface als port die je bijvoorbeeld INotificationService noemt. Vervolgens kun je hier dan een SmsNotifcationService voor schrijven als adapter en daarnaast zou je ook een EmailNotificationService als adapter kunnen schrijven die beide INotificationService implementeren. In de adapter maak je bijvoorbeeld de integratie met AWS Simple Email Service (SES). Als je later toch liever een tool als Sendgrid wilt gebruiken, dan hoef je in de code enkel een SendGridEmailNotificationService-adapter te schrijven maar van je bedrijfslogica blijf je af. Dit maakt het tevens mogelijk om via configuratie van de ene naar de andere te schakelen.

Dit is Ports and Adapters uitgelegd in een notendop. Als je er meer over wilt weten, dan kan ik aanbevelen om de oorspronkelijke uitleg van Alistair Cockburn te lezen1. Daarnaast is de net iets pragmatischere uitleg van Herberto Graça ook erg sterk.

Met Ports and Adapters weet de bedrijfslogica dat het aangeroepen wordt door een functie, maar niet of dat dat een AWS Lambda, Azure Function of een GCP Cloud Function is. Daarnaast weet het alleen “wat” het wilt doen, zoals het opslaan van een object, maar niet “hoe”. Die “hoe” kan dus een MySQL database zijn in AWS, Azure óf GCP.

Kies je er later voor om te migreren van de ene naar de andere provider, dan hoef je alleen de relevante adapters opnieuw te implementeren. De bedrijfslogica van de services blijven intact en dat is waarschijnlijk waar de meest complexe logica zit.

Ports and Adapters is niet alleen handig bij het verminderen van vendor lock-in in de cloud, maar het helpt bij het verminderen van alle integraties. Denk hierbij bijvoorbeeld aan vendor lock-in met je Content Management Systeem (CMS), e-mailservice of je orderservice.

De Ports and Adapters architectuur helpt dus bij het verminderen van een lock-in met een cloud provider, maar het helpt ook bij het verminderen van lock-in binnen de cloud. Stel je hebt momenteel een NoSQL implementatie met bijvoorbeeld DynamoDB van AWS. De integratie is prima, maar je bedrijf groeit en krijgt de vereiste om volledige auditbaar te zijn. Je zou extra logging kunnen toevoegen om iedere actie die gedaan wordt op te vangen, maar je zou ook kunnen denken aan een andere oplossing van AWS zoals Quantum Ledger Database (QLDB). Het enige wat je in je codebase hoeft te doen, is een adapter te schrijven QLDB die voldoet aan de bestaande poorten en je applicatie zal hetzelfde blijven functioneren als voorheen.

Helaas bestaat er in de IT niet zoiets als een gouden hamer dat een oplossing is voor ieder probleem. Ports and Adapters ter voorkoming van cloud vendor lock-in is dat dus ook niet. Neem nou een applicatie waarbij de afhankelijkheden allemaal cloud services zijn en de applicatie weinig meer doet dan het doorgeven van de informatie van de ene naar de andere cloud service. Als je dan gaat migreren naar een andere cloud provider, dan zal blijken dat het “alleen herschrijven van de adapters” betekent dat je eigenlijk de hele applicatie aan het herbouwen bent.

Ontwikkelen in de cloud kan eng zijn maar gelukkig zijn er een paar best-practices die je kunt volgen om wat zekerheid in te bouwen. Ports and Adapters architectuur is daar eentje van. Als dit nou interessant klinkt, dan kan ik je echt van harte aanbevelen om de bijgevoegde links een keer door te nemen.