De voordelen van Domain-Driven Design

Wat bedoelen we precies met het vinden van een gezamenlijke taal? Je stelt met stakeholders vast wat je bedoelt in het proces als je het hebt over een polis, een akte of een locatie. Je bepaalt eerst gezamenlijk met alle stakeholders het bedrijfsdomein en pas daarna de technische invulling. En evenzo belangrijk, qua software zorg je ook dat deze twee zaken gescheiden blijven. Zo blijft het bedrijfsdomein ook begrijpelijk zonder kennis over hoe de software inhoudelijk werkt. Zo werkt het Blueriq Platform ook. In Blueriq is je domein standaard gescheiden van je logica, en het eerste wat je zal moeten maken. Deze aanpak levert ons de volgende voordelen op:
 
Voordeel 1: Verbeterde communicatie en samenwerking 
 
Een belangrijk voordeel van DDD is dat het de communicatie en samenwerking tussen teamleden, belanghebbenden en gebruikers aanmoedigt. Zelfs wanneer je niet allemaal technische kennis hebt. Door een gedeelde taal en begrip van het bedrijfsdomein te bieden, bevordert DDD een beter begrip van het project en zijn doelstellingen. Dit gedeelde begrip leidt tot minder misverstanden en miscommunicatie, wat uiteindelijk resulteert in een efficiënter ontwikkelingsproces. Bij Blueriq hechten we hier veel waarde aan en selecteren we (en leiden we) onze mensen hier op.  De mensen die met Blueriq werken heten daarom ook Business Engineers, omdat we vinden dat ze ook echt met één been in de Business horen te staan. Zodat ze meekunnen praten met de business.
 
Voordeel 2: Flexibiliteit en schaalbaarheid 
 
DDD maakt software-systemen flexibeler en schaalbaarder. Door te focussen op de domeinmodellen creëert DDD een meer modulair en uitbreidbaar systeem. Hierdoor wordt het gemakkelijker om nieuwe functies toe te voegen of bestaande te wijzigen. De truc zit hem erin om op het juiste moment te zien wanneer je een tweede domein te pakken hebt en zaken moet scheidenⁱ. Maar als je dat goed doet, maakt dat het mogelijk om zeer complexe applicaties zeer goed beheersbaar  te houden, omdat elke module zelfstandig is en afzonderlijk kan worden ontwikkeld en getest.  
 
Voordeel 3: Verlaagde ontwikkelingstijd en -kosten 
 
DDD kan ook de ontwikkelingstijd en -kosten verlagen door een duidelijk en beknopt begrip van het bedrijfsdomein te bieden. Door de veelvoorkomende valkuilen van een technische aanpak te vermijden, zorgt DDD ervoor dat de ontwikkelingsinspanningen gericht zijn op de meest kritieke functies en functionaliteit. Deze aanpak vermindert ook de kans op refactoring en technical debt, wat leidt tot meer efficiëntere ontwikkelingscycli. Bij Blueriq wordt veel van het technische werk al voor je gedaan, hierdoor kun je je als Business Engineer focussen op het domein. Door deze aanpak hebben we in slechts een paar weken, dagen en soms zelf een paar uur, volledige applicaties kunnen ontwikkelen. 
 
Conclusie: 
 
Dus zoek je een ontwikkelaanpak die miscommunicatie verminderd, flexibel en schaalbaar is en een korte time-to-market heeft? Kijk dan naar Domain-Driven Design en implementeer het gemakkelijk met het Blueriq platform. 

_____________________________

ⁱ Benieuwd hoe je deze keuzes maakt? Vanuit de Blueriq Academy verzorgen collega Dick van Soest en ik een cursus over hoe, wanneer en waarom je domeinmodellen in Blueriq opdeelt.