Spreek dezelfde taal, trek de grens rond beslissingen

Twee teams bespreken een nieuwe integratie. Iedereen knikt, de afspraak lijkt helder. Weken later blijkt dat "beschikbaar" voor het ene team iets anders betekende dan voor het andere. Niemand heeft gelogen, niemand was slordig. Ze spraken naast elkaar.

Domain-Driven Design heeft voor dit probleem twee begrippen: ubiquitous language en bounded context. Ze worden vaak apart uitgelegd, maar ze horen bij elkaar. De taal vertelt je waar de grens ligt. En de grens vertelt je waarom de taal daar verandert.

Ubiquitous language: zonder gedeelde taal praat je naast elkaar

Ubiquitous language is de taal die business-experts en ontwikkelaars samen gebruiken binnen een domein. Dezelfde woorden staan in de gesprekken, in de user stories, in de tests en in de code. Geen vertaling tussen "wat de business zegt" en "wat de code doet".

Dat klinkt als een detail. Het is het niet. Elke vertaling is een plek waar betekenis verloren gaat. Een analist zegt "order", de ontwikkelaar denkt aan een tabelrij, de tester aan een scherm. Elk van hen bouwt iets dat klopt met zijn eigen beeld, en samen klopt het niet.

Een gedeelde taal maakt misverstanden vroeg zichtbaar. Wie een woord moet definiëren, merkt al snel dat er twee betekenissen in omloop zijn. Dat gesprek is goedkoop vóór de bouw, en duur tijdens de integratietest.

Taal stopt aan een grens

De verleiding is groot om één taal voor het hele bedrijf te maken: één definitie van product, klant of beschikbaarheid. Dat werkt zelden. Neem het woord "beschikbaar" voor een product:

Domein	"Beschikbaar" betekent
Productcatalogus	Het product is bekend en goedgekeurd
Productieplanning	Het product is actief op deze specifieke plant
Verkoop	Er is voorraad die nog niet gereserveerd is

Geen van deze definities is fout. Elk domein heeft het woord nodig voor een andere vraag. Een gedwongen gedeelde definitie wordt ofwel vaag, ofwel past ze bij één domein en wringt ze bij de rest.

Dat een woord van betekenis verandert, is dus geen probleem dat opgelost moet worden. Het is een signaal: hier ligt een grens.

Bounded context: een grens rond beslissingen

De klassieke uitleg is dat een bounded context de grens is waarbinnen een model en zijn taal consistent zijn. Dat klopt, maar het helpt weinig om die grens te vinden. Een bruikbaardere invalshoek:

Een bounded context omvat de beslissingen die een domein neemt, en alle informatie die het nodig heeft om die beslissingen zelfstandig te nemen.

De vraag is dus niet "welke data hoort bij elkaar?", maar "welke beslissing wordt hier genomen, en wat moet je weten om ze te kunnen nemen?". Wat daarvoor nodig is, hoort binnen de grens. Wat niet nodig is, hoort er niet.

In het voorbeeld beslist de catalogus of een product verkocht mag worden. De planning beslist of een plant het kan maken. De planning heeft van de catalogus alleen nodig welke producten goedgekeurd zijn; dat krijgt ze via een event. Elke context neemt zijn beslissing met informatie die hij zelf bezit, en gebruikt "beschikbaar" in zijn eigen betekenis.

Wat deze definitie oplevert in de praktijk

Denken in beslissingen beantwoordt vragen die bij integratie steeds terugkomen:

• Waar hoort een business-regel? In de context die de beslissing neemt. Niet in een integratielaag ertussen, omdat die toevallig alle data ziet. Een vertaallaag vertaalt; ze beslist niet.
• Wat moet er in een event? Genoeg om de ontvanger zijn eigen beslissing te laten nemen. Moet een consumer na elk event terugbellen naar de producer om extra data op te halen, dan is er een verborgen koppeling.
• Wie is eigenaar van welke data? De context die de beslissing neemt, is eigenaar van de informatie die daarvoor nodig is. Andere contexten krijgen een kopie, geen schrijfrechten.
• Waar snijd je een systeem op? Langs beslissingen, niet langs tabellen. Twee beslissingen die altijd samen wijzigen, horen in dezelfde context.

Valkuilen

• Eén canoniek model voor alles. Een bedrijfsbreed datamodel voelt ordelijk, maar dwingt elk domein in dezelfde betekenis. Het resultaat is een model dat niemand echt past.
• Interne staat publiceren. Een event dat gewoon de tabelstructuur van de producer weerspiegelt, lekt diens taal naar buiten. Consumers raken gekoppeld aan details die niet voor hen bedoeld waren. Publiceer business-events, geen database-wijzigingen.
• Stille vertaling. Een integratielaag die betekenis omzet zonder dat iemand het afspreekt, verbergt het taalverschil in plaats van het expliciet te maken. Vertalen mag; ongedocumenteerd vertalen niet.
• Grenzen trekken op organigram. Teams en contexten vallen vaak samen, maar niet altijd. Start bij de beslissingen, en kijk daarna of de teamindeling klopt.

Afsluiting

Ubiquitous language en bounded context zijn twee kanten van hetzelfde inzicht. Binnen een grens spreek je één taal, consequent, van gesprek tot code. Over de grens heen maak je de vertaling expliciet.

Waar die grens ligt, vind je door te vragen welke beslissingen een domein neemt en wat het daarvoor moet weten. Wie die vraag stelt, ontdekt vaak dat de moeilijkste integratieproblemen geen technische problemen zijn. Het zijn twee teams die hetzelfde woord gebruiken voor een andere beslissing.