In applicaties met een complex domein is de domeincode het allerbelangrijkste onderdeel. Máár, bij veel applicaties waar gebruik gemaakt wordt van het traditionele layer pattern, bevat de domeincode ook bijvoorbeeld framework- of database logica. Dat maakt het moeilijker om te testen, het domein te veranderen én te begrijpen. Zonde. Dat kun je eenvoudig oplossen door het in de basis anders aan te pakken en te werken vanuit de essentie: je domeinlogica. Mijn tip: maak gebruik van hexagonale architecturen - bijvoorbeeld via Kotlin - zodat je afhankelijkheden in domeinlogica kunt vermijden.
Het layer pattern met de drie traditionele lagen, presentation – business en persistence, is hét patroon dat alle ontwikkelaars kennen. Maar, daar zitten wel bepaalde nadelen aan verbonden. Nadelen die, als je het vanaf het begin iets anders aanpakt, eenvoudig voorkomen kunnen worden. De bedoeling van zo’n layer pattern is dat de lagen abstract van elkaar zijn. Toch gaat dit in de praktijk vaak niet zo. Het sluipt er snel in dat een stukje logica, dat eigenlijk in de business laag hoort, naar de prestatie laag verdwijnt. Ook als je eigenlijk hebt afgesproken binnen je team dat dit jullie niet zou gebeuren. Het is vaak makkelijk om er ‘even een requirement in te fietsen’. Maar zodra business logica in een andere laag terechtkomt, dan verlies je het overzicht over je requirements. Is dat eenmaal het geval, dan is het einde zoek.
Ik snap het wel: werken met het layer pattern is gemakkelijk en vertrouwd. Wil je werken met een ander patroon, dan moet iedereen die aan de code base gaat werken daar wel bekend mee worden. Toch is het de moeite waard. De business logica is de kern van je applicatie. De user interface is vervangbaar. Een database ook. Daarvan wil je over 5 jaar misschien weer een nieuwe. Kortom: je wil de requirements en business logica daar gewoon niet afhankelijk van maken.
Door je business logica zo schoon mogelijk te houden, zonder afhankelijkheden, blijft je code duurzamer en tijdsvast. Als de techniek verder gaat en je framework of gekozen database niet meer bruikbaar is, dan is het ook mogelijk om mee te veranderen. Durf dus eens een ander patroon te gebruiken, bijvoorbeeld de hexagonale architectuur. Dit draait de rollen om: je business laag wordt centraal en alle andere niet-domein specifieke lagen daarmee afhankelijk van de business laag. De grootste voordelen hiervan zijn dus: focus op je domein, langdurige houdbaarheid en het feit dat je requirements beter te testen zijn. Natuurlijk heb je met software patterns of architecturen nooit een ‘silver bullet’. Er is altijd een keerzijde die je moet afwegen. Bij hexagonal architecture is dit bijvoorbeeld meer mapping of plumping code. De programmeertaal Kotlin helpt je om makkelijker met dit nadeel om te gaan. Wat mij betreft een hele fijne om mee te werken!
Dit artikel is oorspronkelijk gepubliceerd door Topicus.
Terug
