Domeinmodellen uit de tijd?

In deze tijd van agile werken en DevOps tref ik steeds minder domeinmodellen aan. Het is niet langer een vanzelfsprekendheid om een ontwerp met domeinmodellen te onderbouwen. Ik zie steeds vaker dat teams, onder druk van twee- of driewekelijks sprint reviews, te weinig tijd nemen voor documentatie. “Onze software IS het ontwerp!” hoor ik dan. Ze verdedigen hun gebrek aan documentatie met: “Het staat toch in het DevOps Manifesto: Working systems over comprehensive documentation en Working software successfully delivered by sound systems is the primary measure of progress”.

Toch bekruipt me het gevoel dat zulke programmeurs liever code schrijven dan ontwerpen onderbouwen. Het DevOps Manifesto zegt ook: “Continuous attention to technical excellence and good design enhances agility” en “The best architectures, requirements, and designs emerge from self-organizing teams”. Dit laatste lijkt dus juist prioriteit te geven aan een goed ontwerp! De juiste balans tussen ontwerp en bouw, tussen denken en doen, is waar het Manifesto echt om vraagt.

Wetenschappelijk onderzoek naar Domain Driven Design toont aan dat mensen die een opdracht beginnen met het maken van een domeinmodel zich sneller inwerken in de materie. Het maken is belangrijker dan het hebben van een domeinmodel, omdat je de chaotische input heel snel in je hoofd ordent. Bij iedere nieuwe klantopdracht vraag ik dan ook steevast aan mijn opdrachtgever om de meest relevante stukken, die ik dan met blijdschap -in overvloed- in ontvangst neem. Dit materiaal biedt me namelijk de gelegenheid om een eerste domeinmodel te maken. Na het maken van het eerste concept ga ik langs de gesprekspartners met wie ik toch kennis moet maken. Ik haal dan op of ik ze goed begrijp, en laat me geduldig uitleggen waar ik het verkeerd heb of dingen over het hoofd zie, zodat ik mijn model kan bijwerken. Zo helpt het domeinmodel bij de afbakening en analyse van het vraagstuk. Hoe waardevol! En het echte oogsten moet dan nog beginnen…

Een domeinmodel kan de gemeenschappelijke taal visualiseren en helpt je hierover afspraken te maken. Dat voordeel ervaar ik als anderen dezelfde dingen op een andere manier benoemen. Ik kan dan vrij simpel de taal die ik hoor “ijken” met mijn domeinmodel om vast te stellen of “ik het snap” (ofwel: wat ik hoor past in mijn domeinmodel) of niet. Fantastisch is het hoe gemakkelijk je in gesprek raakt over een domeinmodel en zo controverses kunt beslechten door verschillen in taal bloot te leggen. Zo help je de voortgang in een project.

Domeinmodellen kennen nog andere voordelen, ze kunnen: een informatiesysteem afbakenen om een high-level design te maken; overlap in een applicatielandschap inzichtelijk maken om vereenvoudiging voor te stellen; een opstap opleveren naar een formele specificatie om betrouwbare systemen te maken en van een domeinmodel kun je een geautomatiseerd database schema afleiden, zodat je een project kunt kickstarten.

Maar wanneer is een domeinmodel eigenlijk goed? Bij het googlen van “domain model example” krijg ik rijp en groen door elkaar, dus de kwaliteit spreekt niet vanzelf. Voor mij is een domeinmodel is pas goed als het zijn doel dient, want een informatiesysteem bouwen stelt bijvoorbeeld andere eisen dan afspraken over een taal. Meer verdieping, al dan niet via een cursus, is nodig om de voordelen van een domeinmodel ten volste te benutten. Een plaatje maken in Visio volstaat dan niet. Iedere business consultant, architect en ontwerper zou wat mij betreft domeinmodellen tot in de puntjes moeten beheersen om als informaticus bij te dragen aan het succes van je klanten. Maar ook voor je professionele ontwikkeling en werkplezier!

Door: Stef Joosten