Hoe je met domain-driven design kostbare misverstanden voorkomt
Als je pech hebt, heb je het wel eens meegemaakt. Je hebt als organisatie veel geld en tijd uitgegeven aan het bouwen van een nieuw systeem en nu puntje bij paaltje komt, blijkt er een aantal grote fouten in te zitten. Op centrale plekken is er gewerkt met verkeerde aannames, waardoor de applicatie structureel niet kan wat het wel had moeten doen om business waarde te creëren. Dus dan maar aanpassen – met alle vertraging en extra kosten die daarbij komen kijken. Of accepteren dat het minder goed gaat werken – met extra benodigde handmatige acties tot gevolg. Al met al een dure grap.
Aannames, de moeder van alle..
Een ongeluk zit vaak in een klein hoekje, zeggen ze. En dat geldt ook voor aannames en cruciale design-vragen. Neem het concept ‘klant’. Iedereen weet wat je daarmee bedoelt. Toch?
Nou, dat valt tegen.
- Want kunnen al jouw klanten ook met een account inloggen op jouw platform?
- Of kan een klant zelfs meerdere gebruikersaccounts hebben?
- Of een gebruikersaccount juist meerdere klanten beheren?
- En heeft een klant altijd maar één (fysiek) adres, of meerdere adressen?
- Mogen twee klanten hetzelfde adres hebben?
- Etcetera.
Voor je het weet mis je hierin een belangrijke afslag, en blijkt je software niet goed om te kunnen gaan met juist díe definitie van ‘klant’, die voor jou essentieel is. Zie dat nog maar eens te herstellen.
Domain-driven design kan je als organisatie helpen om dit soort kostbare misverstanden te voorkomen.
Wat is het?
Domain-driven design is een set aan werkprocessen en technieken, die ervoor zorgen dat de business en de techniek dezelfde ‘taal’ spreken. Én dat die taal op een structurele manier wordt ingebed in de applicatie. Centrale concepten binnen een (business) domein krijgen een centrale rol in de te ontwikkelen software.
In nauwe samenwerking tussen software developers en domein-experts vanuit business zijde wordt deze nieuwe gedeelde taal – ook wel ubiquitous language genoemd – vormgegeven en gegoten in een domain model. De taal van de business is daarbij leidend. In het model bevinden zich alle belangrijke domeinconcepten en hun relaties tot elkaar. Alle belangrijke beslissingen in het project, van nieuwe features tot architectuurkeuzes, worden genomen met het domein model in het achterhoofd. De software wordt dus ook vanuit dat model ontworpen.
Hoewel dit misschien in eerste instantie klinkt als een eenmalige exercitie, is het dat niet. Zowel in de eerste design fases als gedurende de levensloop van het product is het belangrijk om aandacht te blijven schenken aan het domain model. Zodat deze zich ook mee kan ontwikkelen door de tijd.
Wanneer pas je DDD toe?
In een rechttoe-rechtaan project, is het de vraag of Domain-driven Design veel voordelen oplevert. Juist bij projecten met een complex domein en dus in algemene zin een hoge mate van complexiteit, kan de inzet van DDD een investering zijn waar je als organisatie veel baat bij kunt hebben. Omdat het duurzame software oplevert en kostbare misverstanden worden voorkomen. Maar ook omdat het voor enorm veel extra inzicht zorgt in je eigen bedrijfsprocessen.
Want zeker bij grote bedrijven is die kennis vaak verspreid over meerdere afdelingen en personen. Één iemand weet bijvoorbeeld alles van facturatie, terwijl twee collega’s van een andere afdeling weer expert zijn op het gebied van leveringen, etcetera. Domain-driven design brengt al deze personen én hun kennis samen en zorgt voor een voor iedereen inzichtelijk model. Alleen al dit gedeelde inzicht kan enorm waardevol zijn – zelfs als software ontwerpen helemaal niet aan de orde is.
Om de investering goed uit te laten pakken, is er nog wel een aantal zaken om rekening mee te houden:
- De zogenaamde domein-experts spelen een cruciale rol. Dit zijn die personen in je organisatie met veel kennis over (delen van) je business en het domein waarbinnen het te ontwikkelen product zich begeeft. Selectie van de juiste domein-experts én het structureel betrekken van deze collega’s bij het project is essentieel om de volledige potentie van DDD te benutten.
- Zorg dat het hele team – van product owner tot en met software developers – goed op de hoogte is van de principes van DDD. En van de processen en technieken die in het specifieke project worden ingezet.
- Blijf gedurende het hele project – en eigenlijk de levensduur van het product – aandacht besteden aan het domein model. Zorg ervoor dat deze niet verwaterd en de software wordt doorontwikkeld zonder nog met het domein rekening te houden. Wat je wilt voorkomen is dat de baten van DDD daarmee ook verloren gaan en het risico op dure misverstanden flink toeneemt.
Hoe Enrise gebruik maakt van Domain-driven Design
Bij Enrise zijn we fan van DDD. Kennis van het domein en een eenduidige taal die daar goed bij past, helpt enorm om je software flexibel en beheersbaar te houden naar de toekomst toe. En het maakt de communicatie met de klant alleen maar makkelijker. Daar waar we (elementen van) DDD hebben toegepast (bijv. hexagonal design), zien we dat code veel “logischer” samenwerkt en minder als spaghetti aan elkaar hangt. Veel voordelen dus.
Tegelijkertijd wegen we wel bij elk project af in hoeverre tools en technieken uit DDD ons vooruit gaan helpen. Niet elk project heeft voldoende complexiteit om DDD een waardevolle investering te laten zijn. Denk bijvoorbeeld aan een simpel content management systeem of blog. En niet elke klant is zo georganiseerd dat de juiste domein-experts kunnen worden aangehaakt en in brede zin aan de voorwaarden voldaan kan worden om DDD tot een succes te maken. Dus hoewel we 100% staan achter de filosofie van Domain-driven design, kijken we per klant en per project welke elementen uit de DDD toolbox ons gaan helpen om in die situatie tot succes te komen.
