Wat is een Bounded Context?

Een van de echte innovaties van Domain-Driven Design is het begrip Bounded Contexts.

Sinds de beginjaren van softwareontwerp kijken we naar modularisatie als een manier om complexiteit te beheersen. Die modularisatie gebeurt meestal op twee niveaus:

Technische scheiding: we splitsen code op in modules of componenten; bibliotheken en packages; versiebeheerrepository's; apps, services en microservices; en allerlei onafhankelijk deploybare eenheden. Die scheiding volgt vaak ook de technologie: bv. een Javascript-frontend met een Ruby-backend, of een C#-service die de verantwoordelijkheden voor machine learning delegeert aan een Python-applicatie.
Domeinscheiding: we kijken naar de bedrijfsdomeinen en splitsen de software op volgens grenzen die al in het bedrijf bestaan, bijvoorbeeld Boekhouding, Verkoop, Verzending.

Kanttekening: scheiding gebeurt ook om organisatorische redenen. Maar wees voorzichtig. Er zijn redenen waarom je je Bounded Contexts en domeinen niet één-op-één op elkaar zou moeten leggen.

Bounded Contexts voegen een derde as van scheiding toe. Hoewel veel auteurs geen onderscheid maken tussen domeingrenzen en Bounded Context-grenzen, dienen ze een ander doel. Het blijkt dat deze vorm van scheiding een veel pragmatischere manier is om de complexiteit van softwaresystemen te beheersen. Dus, wat is een Bounded Context?

Het probleem

Wanneer we een softwaresysteem bouwen, werken we met mentale modellen van hoe het bedrijfsdomein werkt en hoe ons systeem werkt, en hebben we een taal om erover te praten. Domain-Driven Design legt veel nadruk op het expliciet maken van die modellen en talen. Door samenwerking tussen engineering en domeinexperts aan te moedigen, zorgen we ervoor dat die modellen en talen gedeeld worden.

In een grote, complexe organisatie vind je:

dubbelzinnigheid, zoals woorden die in verschillende delen van de organisatie een andere betekenis hebben
variatie in bedrijfsregels en hun interpretaties
domeinmodellen en datamodellen die gelijkaardige domeinconcepten dekken, maar anders gestructureerd zijn
bedrijfsprocessen die op verschillende plaatsen net iets anders geïmplementeerd zijn

Proberen om één universele taal en één universeel model te maken voor alle softwaresystemen van de organisatie, is gedoemd te mislukken. Niemand kan alles begrijpen, dus is het onmogelijk om een consistent model voor alles te maken.

Begrijpelijkheidsgrenzen

Een goede manier om een intuïtie voor Bounded Contexts te ontwikkelen, is ze te zien als begrijpelijkheidsgrenzen.

We trekken een lijn, en binnen die lijn zijn de taal en het model consistent, samenhangend en goed begrepen. Idealiter kunnen we samen ons probleem oplossen, omdat we alles binnen die grens kunnen begrijpen. De taal en het model horen samen, want om A te begrijpen moeten we B en C begrijpen, en om B te begrijpen moeten we A en C begrijpen, dus willen ze logischerwijs samen gegroepeerd worden.

Belangrijk is dat we die grenzen trekken zodat we erbinnen kunnen blijven. Binnen de grens hebben we een heel consistente taal zonder dubbelzinnigheid, consistente bedrijfsregels en een model, maar buiten die grens garanderen we dat niet. Zo kunnen we dubbelzinnigheid toelaten tussen contexten, maar niet erbinnen.

Dit is fundamenteel een techniek voor het team om complexiteit te beheersen. Computers geven niet om onze mentale modellen en de begrijpelijkheidsgrenzen die we trekken. Ze dienen om het systeem zelf beter te begrijpen, en het systeem opdelen in kleinere bounded contexts komt ons ten goede wanneer we in complexe omgevingen bouwen.

Bounded contexts trekken is het vakmanschap van de softwareontwerper

Er zit een kunst in het trekken van een waardevolle bounded context. Te klein en het loopt mis, omdat je om één ding te begrijpen nog steeds moet begrijpen wat er binnen de andere grenzen zit. De kunst van systeemontwerp is dus uitzoeken welke dingen het zinvol is om samen te begrijpen, en welke dingen niet van elkaar afhangen.

Natuurlijk moeten de verschillende systemen en bounded contexts communiceren, dus je hebt een protocol nodig om die communicatie te laten verlopen, maar als er veel communicatie en veel taal nodig is om elkaar te begrijpen, dan is de grens hoogstwaarschijnlijk niet zo goed.

Het is dus in de eerste plaats een lijn rond de taal en het model. Het is niet noodzakelijk een systeemgrens. Je kunt een bounded context hebben die over twee systemen of services verspreid is, of één systeem met meerdere bounded contexts. Het is echt een taalkundige grens, een semantische grens, een begrijpelijkheidsgrens; een manier om dingen te groeperen die samen begrepen kunnen worden en samen begrepen moeten worden. Dat is het ideaal, maar pragmatisch gezien kunnen er andere redenen zijn om de grenzen anders te trekken. Dat is de trade-off die de ontwerper moet maken.

De essentie van ontwerpen is het doel van het systeem begrijpen, de middelen en de beperkingen binnen het systeem begrijpen, en dan de beste ontwerpbeslissingen nemen op basis van beperkte kennis. Bounded contexts zijn dus een instrument om ons te helpen omgaan met complexiteit.

Waar je meer kunt leren: