Softwarecode bestaat uit meerdere lagen die soms te nauw met elkaar verweven zijn, wat de vrijheid van ontwikkelaars inperkt. De ‘clean architecture’-benadering zorgt ervoor dat je met een schone lei kan coderen.
Wat hebben softwarecode en lasagne met elkaar gemeen? Dit is niet het begin van een flauw raadsel, maar een vraag die ontwikkelaars al lang bezighoudt. Net zoals een lasagne, bestaat code uit meerder lagen die samen een geheel vormen. Het samenspel tussen die verschillende lagen doet je recept slagen of mislukken.
In een perfecte lasagne smelten de verschillende lagen samen, maar voor code is dat niet de ideale bereidingswijze, leren we van Maarten Vandeperre. Hij is geen beroepschef, maar Specialist Solutions Architect bij Red Hat. Clean architecture stapt af van het idee dat softwarelagen met elkaar verweven zijn en streeft net naar een striktere afscheiding tussen niveaus. Zo hoeft een ontwikkelaar niet te vrezen dat veranderingen in één laag de hele architectuur beïnvloeden.
Ajuinstructuur
De grondlegger van de clean architecture-benadering is Robert C. Martin. In 2008 schreef hij het boek The Clean Coder: een boek dat voor Vandeperre een belangrijke inspiratiebron is geweest. Martin deelt softwarecode op in vier niveaus, volgens het principe van een ajuinstructuur.
Vandeperre gidst ons door een visuele representatie van een clean architecture. “In de buitenste laag heb je de runtime configuratie, welke de lijm vormt, waarmee de onderliggende lagen, of een subset ervan, in een uitvoerbaar programma gegoten worden. In de op een na buitenste laag van de ajuin zit de infrastructuurlaag, die onder meer datebases, netwerk en webframeworks bevat. In deze laag zit niet veel code, maar wel noodzakelijke verwijzingen naar details in de code.”
“Pellen we deze laag af, komen we op de ‘adapterlaag’ uit”, vervolgt Vandeperre. “Deze laag legt de buffer tussen de ‘binnenkant’ en de ‘buitenkant’ van je code. Hier worden de gateways en controllers gedefinieerd die het dataverkeer tussen de verschillende niveaus reguleren.”
Laag per laag zakken we meer af naar de kern van je code. In de derde laag worden applicatiespecifieke bedrijfsregels gedefinieerd voor concrete use cases van een applicatie. De binnenste laag tenslotte is de domeinlaag. Hier worden bedrijfsbrede gegevensstructuren en functies gebeiteld.
Hou je opties open
Clean architecture zet een duidelijke hiërarchie tussen deze niveaus. Vandeperre legt uit: “Wees strikt in waar afhankelijkheden in je codestructuur mogen zitten. Deze mogen enkel naar binnen gericht zijn, wat betekent dat buitenlagen afhankelijk kunnen zijn van binnenlagen, maar niet omgekeerd om het risico op regressie te verlagen. Je kan bij clean architecture nog altijd stukjes code dubbel hebben, maar die zijn dan veel meer geïsoleerd van elkaar. De binnenste laag moet zo onafhankelijk mogelijk zijn. Dit is echt cruciaal om clean architecture te laten werken.”
“Op deze manier hou je je opties open: je hoeft niet te trouwen met een technologie”, gaat Vandeperre verder. “Als je te afhankelijk bent van een bepaald stukje software, database of bibliotheek, kunnen er problemen ontstaan. Ik zie het nog vaak gebeuren dat ontwikkelaars bijvoorbeeld Quarkus toelaten in de kern van hun code. De enige toegestane afhankelijkheid hier is de programmeertaal zelf, maar dat betekent ook niet dat alles wat bij een bepaalde programmeertaal hoort, ook mee in je kern hoeft te zitten.”
Deze manier van werken biedt veel voordelen bij het testen van je code. “Testen verloopt veel vlotter omdat je de kern niet aantast”, gaat Vandeperre verder. “Je kan in elke laag afzonderlijke testprocessen opstellen om te bepalen waar eventuele fouten zitten. De kost om dingen die niet werken buiten te smijten verkleint, omdat aanpassingen die je aan de infrastructuur aanbrengt geen invloed hebben op de kern. Dit gunt je meer vrijheid om nieuwe dingen uit te proberen.”
Als je te afhankelijk bent van een bepaald stukje software, kunnen er problemen ontstaan. Gun jezelf de vrijheid om nieuwe dingen uit te proberen.
Maarten Vandeperre, Specialist Solutions Architect Red Hat
Van binnen naar buiten
Naast testen moet een schone architectuur ook het draaien en onderhoud van codes bevorderen. “De volgorde van ontwikkelen wordt in feite omgedraaid: in plaats van van buiten naar binnen te werken, werk je nu van binnen naar buiten. Je kan eerst de businesslogica en het datamodel ontwikkelen. Pas als je weet dat de kern goed zit, kan je de andere lagen verder opbouwen. Net daarom is het zo belangrijk dat je kern onafhankelijk is: eens hier een afhankelijkheid insluipt, kan je die nog maar heel moeilijk buitenwerken”, zegt Vandeperre.
lees ook
De illusie van DevOps doorprikt: zoeken naar een perfecte cirkel
Vanuit zijn eigen ervaringen deelt Vandeperre nog een laatste gouden tip om aan de slag te gaan met clean architecture: “Denk ook voorbij de principes van de code zelf en vergeet de infrastructuurlaag niet. Dit mag dan wel aan de buitenkant van je code zitten, dit is de laag die uiteindelijk alles doet samenhangen. De infrastructuur moet je dan ook niet als één laag zien, maar een combinatie van meerdere subniveaus, zoals interfaces, netwerk, databases, etc. Ik kom vanuit de softwarewereld, dus dit heb ik zelf ook tot mijn eigen scha en schande moeten ondervinden.”