Hoe je een ubiquitous language bouwt

"Op een project zonder gemeenschappelijke taal moeten developers vertalen voor domeinexperts. Domeinexperts vertalen tussen developers en nog andere domeinexperts. Developers vertalen zelfs voor elkaar. Vertalen vertroebelt de concepten van het model, wat leidt tot destructieve refactoring van code."

Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software.

In elk team of elke afdeling ontstaat een gedeelde sociale taal die voor hen werkt. Die taal is heel organisch en altijd in beweging. Ze is rommelig en vaak dubbelzinnig, met woorden die in de loop van de tijd van betekenis verschuiven. Het team gebruikt verschillende woorden voor hetzelfde, of gebruikt verschillende woorden om min of meer hetzelfde te bedoelen. Dat is allemaal heel normaal; zo werkt natuurlijke taal, en onze hersenen zijn erg goed in omgaan met die dubbelzinnigheid.

Maar de taal moet precies en ondubbelzinnig zijn wanneer we bij systeemontwerp komen. De aard van software vertelt ons of onze taal fout is of niet. Een spelfout of een vergeten komma breekt de build. In Domain-Driven Design zeggen we dat de taal die je gebruikt in de code en de artefacten dezelfde taal moet zijn die je afspreekt met de business. In plaats van te kiezen voor de domeintaal, die te rommelig is en voortdurend evolueert, of de taal van de developers, die te esoterisch kan zijn, gebruiken we een afgesproken taal om in ondubbelzinnige termen te praten. Dat is een taal die bewust ontworpen is, gebaseerd op het domein, tussen de stakeholders uit engineering en business. Die taal is nauw gekoppeld aan individuele Bounded Contexts, wat betekent dat de taal die we gebruiken om dingen te beschrijven in de ene bounded context kan verschillen van die in een andere.

Het vergt een bewuste inspanning van het team om de juiste woorden te vinden. Het benoemen zelf is vaak een over het hoofd gezien onderdeel van softwareontwerp. Wanneer we volhouden om nieuwe namen te gebruiken in diagrammen, gesprekken en code, kunnen we dubbelzinnigheid en misverstanden gladstrijken en zo een beter model bouwen en, bij uitbreiding, een coherenter en performanter systeem.

Welke woordenschat moet afgesproken worden?

Eric Evans, die Domain-Driven Design benoemde en populariseerde in zijn boek "Domain-Driven Design", zegt dat de ubiquitous language de kernelementen moet benoemen die betrekking hebben op het model en het systeem dat je bouwt. Daartoe behoren:

• Klassen, types en belangrijke operaties

• Termen om regels te bespreken die expliciet gemaakt zijn in het model

• Termen uit de organiserende principes op hoog niveau die aan het model opgelegd zijn

• Namen van patronen die het team doorgaans toepast op het model

Hoe formeel moet die taal zijn?

De formaliteit van de taal hangt af van je context. Als je een snel bewegende start-up bent, kan formeel betekenen: een korte discussie tijdens domain discovery om de kernbegrippen af te spreken. Als je in een levenskritisch domein zit zoals medische apparatuur, kan formeel betekenen dat je een strikt RFC-proces volgt dat strikt geïmplementeerd wordt. Als je de opdracht krijgt om de volgende versie van de HTTP-specificatie te schrijven, is formeel iets wat voor de komende 100+ jaar als dé manier van werken zal gelden.

Formaliteit is contextueel, maar ze is altijd formeler dan de dagelijkse taal die mensen in het domein gebruiken. Als de taal evolueert, moeten we de ubiquitous language in onze code en modellen, documentatie, tests, enzovoort mee laten evolueren.

Wanneer begin je met het ontwikkelen van een ubiquitous language?

Een ubiquitous language ontstaat vaak tijdens collaboratief domeinmodelleren. Je kan niet modelleren zonder enige overeenstemming over taal, anders heb je alleen een tekening en woorden zonder betekenis. Tijdens het modelleren worden de kernterminologie en de benaming van sequenties verduidelijkt en afgesproken. De taal en het model zijn dus heel nauw verbonden. Wanneer we iets nieuws definiëren, definiëren we het in relatie tot andere dingen in het domein of het model.

Een eenvoudig voorbeeld is het ontwerp van een e-commerceplatform. Als een "Order" bestaat uit een lijst van "Products" en "Quantities", dan is dat een model, omdat we zeggen dat er een relatie is tussen de "Order" en het "Product". Maar we moeten ook begrijpen wat het "Product" is om een "Order" te definiëren. Het heeft geen zin om te zeggen dat een "Order" een lijst van "Products" is zonder te weten wat het "Product" is. De taal zal altijd gedefinieerd worden in termen van het model, en de relatie tussen die dingen beschrijft het model.

Teams zouden vroeg in het ontwerpproces aan het verduidelijken van de taal moeten werken, om misverstanden tussen de stakeholders uit engineering en business weg te nemen en zo coherentere software te bouwen.

Samengevat: wanneer de Ubiquitous Language goed gebruikt wordt, zou een niet-technische domeinexpert de code kunnen lezen en begrijpen wat ze doet. Maar zelfs zonder zo ver te gaan, maakt die gedeelde taal de communicatie over de software veel vlotter, zodat de resulterende software veel beter aansluit bij de noden van de business.