Spraakverwarring kan tot grappige taferelen leiden. In de film Clockwise met John Cleese was het zelfs de rode draad. Ook iemand als Benny Hill wist met de woorden ‘youth in Asia’ en ‘euthanasia’, die hetzelfde klinken, wel raad. Als bij een ontwikkelproject het development team en de opdrachtgever elkaar niet goed begrijpen, is de lol er echter snel vanaf. Dat is te voorkomen met Domain Driven Design.
Interpretatieverschillen
Dit is een aanpak die bestaat uit een aantal middelen en patterns om complexe software te ontwerpen en te ontwikkelen. Bij Delta-N hebben we deze aanpak een tijdje geleden al omarmd. En met succes. Dat miscommunicatie bij software development altijd op de loer ligt, is natuurlijk niet nieuw. Techniek en business zijn nou eenmaal twee verschillende werelden en ontwikkelaars denken logischerwijs vooral in en aan de techniek. Regelmatig vragen stellen als ‘Waarom wil je dit?’ en ‘Lost dit jullie businessprobleem op?’ kan al de nodige ruis (en daarmee verspilling van tijd en middelen) voorkomen. Daarnaast kunnen bepaalde concepten of termen voor verschillende deelnemers en rollen ook verschillende betekenissen hebben.
Dezelfde taal spreken
Zo hebben verkopers doorgaans een andere interpretatie van het woord ‘order’ dan pak ‘m beet een ERP-consultant. Ook woorden als ‘user’ c.q. gebruiker of ‘account’ betekent niet voor iedereen precies hetzelfde. Omdat veel interpretaties ook op andere manieren contextgebonden zijn, moet iedereen dezelfde taal spreken. Hoe complexer het probleemdomein, hoe groter het belang om op één lijn te zitten. Om alles hanteerbaar te houden, worden dit soort domeinen immers vaak in subdomeinen onderverdeeld. Ontworpen in context van bepaalde business capabilities als een afgebakend geheel, ofwel een Bounded Context.
Kennis spreiden
Hierbij is het dan ook zaak dat over het model op eenduidige wijze wordt gesproken door de verschillende lagen, dus van de business tot en met het ontwikkelteam. Door het model systematisch in je software-implementatie door te vertalen, wordt het een stuk eenvoudiger om software later op punten aan te passen wanneer de business daarom vraagt. Daar word je als team en uiteindelijk als organisatie wendbaarder van! Bijkomend voordeel van Domain Driven Design is dat de continuïteit beter gewaarborgd is. Waar je voorheen afhankelijk was van twee personen, namelijk de architect en de domeinexpert, wordt alle kennis bij DDD verdeeld over meerdere personen en niveaus.
Meer weten over Domain Driven Design?
Het feit dat DDD een uitstekend middel is bij het ontwerpen en ontwikkelen van microservices is hierbij mooi meegenomen. Bij Delta-N zijn we ervan overtuigd dat DDD door de hele cyclus, van creatief idee en specificaties tot en met code en testen leidt tot betere en meer wendbare software. Daar is wat ons betreft geen woord Chinees bij. Voor meer informatie of gericht advies kun je altijd contact opnemen met Aleksander van ’t Hooft via aleksh@delta-n.nl.
