SATURN conference - Dag 2 - Architecture hoisting

Deze bijdrage is geleverd door Rogier Schrama

Dag 2 van de SATURN conference is achter de rug. Deze dag stond in het teken van de volgende onderwerpen:

• Architecture hoisting
• System design consequences of using DevOps practices
• Big Data – Architecture and technologies

Architecture hoisting

Architecture hoisting is een naam voor een techniek die niet nieuw is. In de meeste gevallen maakt iedere architect en/of developer er gebruik van. Het omvat het afdwingen van architecturale constraints middels mechanismen in de source code. Dus eigenlijk de architectuur van een applicatie zo inrichten dat het ‘vanzelf’ een bepaalde werkwijze stimuleert of afdwingt. Het tegenovergestelde van architecture hoisting is door middel van bijvoorbeeld geschreven standaards en richtlijnen een ontwikkelaar ‘vertellen’ op welke wijze bepaalde zaken moeten worden geïmplementeerd.

Er is een aantal bekende mechanismen dat kan worden toegepast om architecture hoisting te bewerkstelligen. Je kunt hierbij denken aan een language runtime, DSLs, frameworks, layers en libraries. Al deze mechanismen zijn erop gericht om ervoor te zorgen dat de ontwikkelaar zo min mogelijk expliciet rekening hoeft te houden met de constraints waaraan hij of zij gebonden is. Dit beperkt de complexiteit van de materie waarmee een ontwikkelaar zich bezig houdt. Op het eerste gezicht lijken dit open deuren, maar de architecture hoisting techniek definieert een aantal zaken die de ontwikkelaar of architect meer bewust maken van welke source code mechanismen op welk moment kunnen worden toegepast om architecturale constraints af te dwingen.

‘intensional’ en ‘extensional’ constraints

Belangrijk in deze context is het onderscheid tussen de principes ‘intensional’ en ‘extensional’ constraints (geen typo’s), afkomstig uit de predicatenlogica. Een extensional constraint heeft betrekking op specifieke elementen in de architectuur (bv. ‘we onderkennen modules X en Y’). Intensionele constraints zijn algemene constraints (bv. ‘alle communicatie vindt plaats via http’). Extensional constraints corresponderen expliciet met elementen in de implementatie. Voor intensional constraints is dit niet het geval. In die laatste situatie geldt dat er zogenaamde ‘guiderails’ geïmplementeerd moeten worden die de gewenste constraints afdwingen. Voor het hiervoor genoemde voorbeeld (communicatie via http) kan een voorbeeld van een guiderail een vanuit de architectuur voorgeschreven library zijn, die door de developers moet worden gebruikt om communicatie via http in alle gevallen te garanderen.

De uitdaging zit hem in het onderkennen van de verschillende constraints en het vinden van de juiste methode om deze af te dwingen door middel van mechanismen in de source code. Of juist niet, zodat de ontwikkelaar moet vertrouwen op zijn of haar eigen discipline om te voldoen aan bepaalde constraints. Er zou ook voor een tussenvorm gekozen kunnen worden in de vorm van static code analysis of IDE plugins die de source code valideert tegen specifieke constraints in plaats van mechanismen in de code zelf.

Conclusie

Uiteindelijk komt het allemaal neer op de beperking van complexiteit door het verkleinen van de ‘design space’ met als gevolg een vermindering van de kans op fouten.