Hexagonal Architecture: weg met die taart en neem een keer een sinaasappel!

Door E-sites, E-sites
25 september 2015 - 2262 x bekeken - Categorie├źn: Tech

Nee, dit advies gaat niet over het aanpassen van je eetpatroon, maar over software architectuur. Al langere tijd hebben we, met een aantal van onze back-end developers, het idee dat de manier waarop we onze applicaties ontwikkelen en de structuur die we daarbij gebruiken niet in alle gevallen optimaal is. Tijdens conferenties als PHPBenelux en DPC zagen we andere manieren om onze software te structureren. Maar in sessies van 45 tot 60 minuten past nu eenmaal niet genoeg concrete informatie, waardoor het lastig bleef om dit in de praktijk te brengen. Omdat we toch graag een stap verder wilde komen, besloten we eerder dit jaar Matthias Noback te vragen zijn Hexagonal Architecture training bij ons op kantoor te geven.

Onder PHP developers is MVC het de facto design pattern voor webapplicaties. Simpel gezegd: structureer je applicatie als een taart, met meerdere losse lagen.



De gebruiker ziet de View en heeft hier interactie mee. Dat wat de gebruiker doet komt vervolgens bij de Controller terecht, die de inputwaarden uitleest en naar het Model stuurt zodat deze het kan verwerken. Vervolgens haalt de Controller de relevante data uit het Model en geeft deze aan de View zodat de gebruiker voorzien wordt van de juiste informatie.

Hoewel dit voor eenvoudige applicaties prima werkt, komen we in meer complexe situaties al snel in de problemen. Wanneer we bijvoorbeeld een dynamisch opgebouwd formulier (met meerdere onderdelen die allemaal anders behandeld worden) moeten gaan verwerken, leidt dit al snel tot lange lappen code in zowel de Controller als Model lagen. Niet alleen staat dit onderhoudbaarheid en herbruikbaarheid in de weg, de code is hierdoor ook lastig te begrijpen en lelijk.

Wat Matthias ons leerde is hoe we dit stuk 'presentatie aan en interactie met de gebruiker' kunnen scheiden van de daadwerkelijke werking van de applicatie. Dit doen we onder andere wanneer we het hebben over twee lagen. Je spreekt niet langer over 'boven' en 'onder' (of 'links' en 'rechts', of welke richting je ook kiest), maar over 'binnen' en 'buiten'. Hoe verder naar binnen een laag zich bevindt, hoe meer dit gaat over het oplossen van bepaalde problemen die specifiek zijn voor de applicatie. Ga je juist verder naar buiten dan kom je bij lagen die meer en meer met 'de buitenwereld' te maken hebben.



Deze architectuur (of wellicht beter: dit idee) is bekend onder meerdere namen, zoals de hexagonal architecture/ports and adapters, onion architecture en de clean architecture.

Centraal staan de zogenaamde entiteiten, de 'dingen' waar de applicatie iets mee doet. Bij een weblog heb je bijvoorbeeld 'artikel' en 'reactie' en bij een webshop zijn voorbeelden van entiteiten 'product', 'klant' en 'bestelling'. Deze entiteiten bevatten de logica die nodig is voor de meest belangrijke gebeurtenissen binnen de applicatie.

Daarbuiten staan de zogenaamde 'use cases', de 'acties' die de applicatie ondersteunen. Voor een webshop kan dit zijn 'klant voegt product toe aan winkelwagen' of 'klant plaatst bestelling'.

Nog een laag verder naar buiten zit de code die de integratie tussen de applicatie en de buitenwereld regelt. Hier vinden we de oude MVC structuur: de Controller om de input op te vangen, het Model welke nu als een soort van toegangspoort naar de Use Cases dient en de View om data, formulieren en dergelijke weer te geven aan de gebruiker. Of misschien vinden we hier wel iets helemaal anders, omdat we geen webbased GUI bieden maar enkel een (REST/SOAP/…) API of command line interface. Met deze nieuwe architectuur is dit ontkoppeld van elkaar wat veel flexibiliteit biedt. Daarnaast vind je hier ook de code die persistentie regelt, connecties naar externe webservices, enzovoort.

Helemaal aan de buitenkant vind je eventuele een externe code, zoals frameworks en ORM’s. Deze code behoort tot de buitenwereld waarmee de integratie laag samenwerkt. Hierbij representeren de verschillende kanten van de hexagoon vaak verschillende soorten buitenwerelden. Eén zijde representeert externe databronnen (databases, webservices, etc.), een andere zijde vertegenwoordigt de verschillende vormen van interactie met de gebruiker (HTTP response, e-mails, SMS alerts) en weer een andere zijde zou de geautomatiseerde test suite kunnen zijn.

Welke lagen je precies hebt is natuurlijk afhankelijk van de specifieke situatie. Wellicht wil je voor de use cases nog een service laag of iets dergelijks toevoegen, wat gewoon mogelijk is. Het exacte aantal lagen is niet heel belangrijk, net als de daadwerkelijke vorm van de hexagoon. Voor een grote applicatie is het mogelijk dat er acht lagen zijn en de hexagoon eigenlijk een icosagoon is. Wel belangrijk is de structuur, de achterliggende gedachte en het feit dat de code van een algemene oplossing voor een probleem naar een specifieke applicatie in een specifieke omgeving (van binnen naar buiten) gaat.

Door op deze manier een scheiding aan te brengen in je applicatie, kun je later gemakkelijk een andere interface schrijven die dezelfde onderliggende logica gebruikt. Deze andere interface kan een API voor interne of externe gebruikers zijn, een command line interface of simpelweg een totaal ander ontwerp voor iets dat functioneel dezelfde website is.

Al met al zeer leerzame informatie, waar we mee aan de slag zijn gegaan! 

 

 

E-sites zoekt developers!

Technologie ontwikkelt zich razendsnel. En wij dus ook. We omarmen nieuwe technologie, experimenteren en investeren. In goede tools en apparatuur. En in jou. Join us! Bekijk onze vacatures.

SOLD OUT: e-Health Convention 2015

Door E-sites

Op dinsdag 29 september gaat de e-Health Convention van start in Pakhuis de Zwijger in Amsterdam. - Lees meer

Lees verder