Waarom het domein in het hart van je software hoort

Een domeinlaag in het hart van je software laat je de oplossing voor het bedrijfsprobleem helder uitdrukken, zonder verstrengeling met accidentele complexiteit

Veel architectuurpatronen zetten het domein in de kern — clean, onion, hexagonal — maar de redenen die ze daarvoor geven zijn niet altijd duidelijk, en de meeste missen het belangrijkste punt.

Een domein in het centrum laat je het bedrijfsprobleem helder uitdrukken, zodat alle betrokkenen het systeem begrijpen, zonder dat je bedrijfslogica moet loswrikken uit technische bekommernissen.

Laten we snel de twee soorten complexiteit definiëren die softwaresystemen bevatten: essentiële complexiteit en accidentele complexiteit.

Essentiële complexiteit is het probleem zelf: wat een contract is, welke invarianten altijd moeten gelden. Die zijn inherent aan het systeem. Accidentele complexiteit bestaat uit de implementatiedetails van de oplossing die we kozen: of we data opslaan in SQL of in bestanden, hoe we payloads formatteren, of hoe we retries beheren.

Met beide soorten complexiteit omgaan is echt werk. Maar het is niet hetzelfde soort werk, en door ze te vermengen worden ze allebei moeilijker te begrijpen en te hanteren.

De database die de vraag beantwoordt of de message bus die de aankondiging vervoert, blijven aan de buitenkant. De business geeft niet om die details; ze geeft er alleen om wanneer regels geschonden worden. Duw het hoe naar buiten, zodat het wat leesbaar blijft.

De echte winst gaat dieper dan leesbaarheid. Een propere domeinlaag is de plek waar je een expliciet model van de business vastlegt, uitgedrukt in de ubiquitous language die domeinexperts en developers werkelijk delen. De code is daardoor niet langer een losse interpretatie van de business, maar wordt het model zelf. Leesbaarheid volgt daaruit: een propere domeinlaag is de plek waar een nieuwe developer, een auditor of je toekomstige zelf het systeem kan begrijpen zonder eerst lagen infrastructuur te ontcijferen. In de domeinlaag woont de helderheid.

Het domein testen en infrastructuurkosten verlagen

Twee andere grote voordelen komen naar voren wanneer het domein in het hart van je software zit.

Het domein testen wordt eenvoudiger. Zonder afhankelijkheden van databases of netwerken kun je de echte bedrijfsregels rechtstreeks testen, in plaats van te worstelen met complexe technische bekommernissen. De tests blijven snel, deterministisch en gericht op de logica die ertoe doet.
Infrastructuurkeuzes worden minder belangrijk. Een database of een message queue vervangen — hoe zeldzaam dat ook is, en in de meeste gevallen geen echte zorg — wordt een stuk eenvoudiger. Omdat het domein alleen van abstracties afhangt, kun je die technische keuzes later maken of ze wijzigen met minimale impact op je bedrijfslogica.

Beide voordelen vloeien natuurlijk voort uit een proper domein, maar het zijn afgeleide voordelen. In de eerste plaats veranderen je tests van complexe technische oefeningen in een propere, expressieve weergave van de bedrijfsoplossing zelf. Daarmee vergeleken is de mogelijkheid om databases of message queues te vervangen slechts een handig technisch bijproduct — een argument dat als onnodige overhead zou overkomen als je het als hoofddoel presenteert. Uiteindelijk zijn deze voordelen waardevol, maar het kerndoel blijft hetzelfde: helderheid over het domein.

Pragmatisme telt ook

Een paar eerlijke kanttekeningen, want dogma richt hier meer schade aan dan goed.

Wees pragmatisch over wat je naar buiten duwt. Niet elke technische bekommernis moet een uitgebreid geabstraheerde port worden. Als je logging behandelt als een externe afhankelijkheid die overal geïnjecteerd en omgekeerd moet worden, heb je accidentele complexiteit toegevoegd in naam van het verwijderen ervan. De prioriteitsvolgorde is wat telt: eerst, kunnen we het bedrijfsprobleem en zijn oplossing helder uitdrukken? Daarna, hoe orkestreren we de technische kant? De eerste vraag wint; de tweede is een afweging, geen regel.

Sommige domeinen zijn vooral technisch. Deze hele aanpak werkt wanneer er een echt bedrijfsdomein te beschermen valt. Als je iets inherent technisch bouwt, zeg maar een tool voor bestandsbeheer, dan valt er misschien maar heel weinig essentieel domein te isoleren. Het patroon forceren voegt dan complexiteit toe in plaats van ze weg te nemen. Hier komt de klacht "dit is gewoon overhead" vaak vandaan, en soms is die klacht terecht. De taak van de architect is om de twee situaties uit elkaar te houden: een rijk bedrijfsdomein heeft enorm veel baat bij een propere kern, een dun technisch domein meestal niet.

Wat verandert met AI

Er is een nieuwere reden om hierom te geven, en die versterkt alles hierboven.

Wanneer je een LLM vraagt om een systeem te wijzigen, werkt die binnen de grenzen van zijn contextvenster. Met een anemisch model — waar de data slechts zakken vol properties zijn en de bedrijfsregels verspreid liggen over controllers, services en queries — moet de AI door veel technische ruis ploegen om het signaal te vinden. Hij leest één plek, maakt een wijziging, en mist een regel die ergens anders woont. Dat soort fragmentatie veroorzaakt productiebugs, en het is dezelfde faalwijze als wanneer je softwaredevelopers dun uitgesmeerd zijn over de hele codebase.

Een rijk domein in het centrum werkt als een beknopte semantische kaart. Omdat de regels rechtstreeks bij de data wonen die ze beschermen, hoeft de AI (of een menselijke developer) alleen het kerndomein te laden om over de bedrijfslogica te redeneren. Hij hoeft de omliggende database- of transportmachinerie niet te begrijpen om de regels juist te krijgen.

Het is als mens ook een stuk eenvoudiger om de nieuwe code te valideren als de enige vraag is: "hoe ziet het domeinmodel eruit?" Je hebt minder code te reviewen en kunt je puur op de bedrijfsbekommernissen concentreren.

Kortom

Houd de essentiële domeinlogica in het centrum van je systeem en duw de accidentele complexiteit naar buiten. Je domeinlaag wordt een expliciet, leesbaar model van de business — eenvoudiger te onderhouden voor mensen, eenvoudiger om over te redeneren voor AI, en moeiteloos te testen.

Probeer het zelf eens. Heb je vragen, neem dan contact op.