Uit de modder blijven met ‘bounded context’

Om te kunnen blijven groeien, moeten we binnen Vollan nadenken over hoe de verschillende applicatie onderdelen intern met elkaar communiceren. In mijn eerdere blog ‘Wanneer is goed goed genoeg?’ ging ik vooral in op de kwaliteit van de code. In deze blog wil ik uitleggen waarom we gebruikmaken van ‘bounded context’ in plaats van een monolithische architectuur. Een monolithische architectuur is een traditionele aanpak voor softwareontwikkeling waarbij alle componenten van een applicatie in één codebase worden samengevoegd en als één geheel worden uitgevoerd.

Met een metafoor kan je dit zien als een te uitgebreide multitool. Waarom voegen we een hamer, zaag en boormachine niet gewoon samen? Dan hebben we alles bij de hand. Dit is niet meer te hanteren, laat staan vast te houden!

Big ball of Mud

Als alle functies en modules in één systeem worden geplaatst en vanuit dezelfde codebase worden aangestuurd, kan dit leiden tot een ‘Big Ball of Mud’. Dit is een term die wordt gebruikt om te verwijzen naar een systeem dat organisch is gegroeid zonder een duidelijke architecturale visie en waarvan de delen nauw met elkaar verweven zijn.Een bounded context kan gezien worden als een mini-applicatie binnen een enkele code base. Hiermee willen we voorkomen dat onderdelen als een brei van verwijzingen naar elkaar wijzen. Als ik terugkom op de metafoor kunnen we soms beter de hamer en zaag los van elkaar maken, het is dan wel allebei gereedschap, maar voor de rest heeft het niks met elkaar te maken. Als ik een foto lijstje ga ophangen wil ik niet mijn zaag meenemen.

Grenzen vaststellen

De scheiding tussen twee onderdelen in softwareontwikkeling is niet altijd even makkelijk. Waar liggen de grenzen? Wij hanteren voornamelijk wat de kern is van een context; kan het zonder een bepaalde eigenschap? Dan hoort deze eigenschap vast in zijn eigen context. Bij een taak is bij ons de kern dat een taak een titel heeft en of deze afgerond kan zijn. Bijvoorbeeld het koppelen van een relatie of reacties van een taak, bevinden zich allemaal in hun eigen ‘bounded context’. Binnen deze contexten zit er allemaal een taak-entiteit, de enige verwijzing dat het om dezelfde taak gaat is de identifier (id).

Ze weten dus bijna niks van elkaar, geen wirwar van verwijzingen, zodat als je een duwtje tegen het ene geeft niet het andere onderdeel om valt. Het blijft relatief klein, makkelijk weg te gooien of te vervangen.

De andere kant

Niet alles komt met alleen voordelen. Er is best wat extra ‘boilerplate’ code, zoals de onderliggende code voor het domein, persistent layer of de presentatielaag (API) naar buiten. Als er nog geen context voor is, wat vaak het geval is, kan je niet zo makkelijk wat velden toevoegen en klaar.

Meer code maakt het gelukkig niet direct moeilijker, de algehele code blijft wel minder complex. We hopen zo uit de modder te blijven en vooral bezig te zijn met nieuwe functionaliteit.

PS We hebben wel een enkele codebase, maar houden de contexten strikt gescheiden met behulp van de tool deptrac.