Soms kom je iets tegen waarvan je meteen denkt: waarom heb ik dat niet eerder ontdekt? Dat had ik bij Domain Driven Design (DDD): een andere benaderingswijze van IT-projecten waarbij er korte, directe lijntjes zijn tussen business en developers. Iedereen spreekt dezelfde taal en weet wat het gezamenlijke doel is waar je naartoe werkt.
En die gezamenlijke taal voer je één op één door in de software. Zo krijg je mooie applicaties waar mensen graag mee werken. DDD is simpel én briljant en ik ben er dan ook erg enthousiast over!
Het probleem
Eerst nog even terug naar hoe het ‘vroeger’ ging – en hoe het er in veel organisaties nog steeds aan toegaat bij IT-projecten. Ik gebruik vaak het voorbeeld van een schuur waar steeds iets aan bijgebouwd is. Een extra ruimte erbij, een verdieping erop, dan weer een extra raam: uiteindelijk is het geen homogene oplossing meer. Eigenlijk kan je beter het schuurtje helemaal platgooien en opnieuw beginnen. Maar ja, dat is zonde, want er is al zoveel tijd en materiaal in geïnvesteerd.
Bij softwareontwikkeling gaat het vaak op een soortgelijke manier. Stel, een zorginstelling heeft behoefte aan een softwareoplossing. Een business-analist gaat ermee aan de slag om het hele spectrum in kaart te brengen en uit te zoeken wat er precies nodig is. Maar met zo’n gedetailleerde analyse loop je kans dat de developers door de bomen het bos niet meer zien, en er hun eigen interpretatie op loslaten om tot werkende software te komen. Zo kan er in de beginfase al verwarring ontstaan – nog voordat er een regel code is geschreven.
Het risico is dan dat iedereen het wiel weer opnieuw probeert uit te vinden en eigen oplossingen verzint voor problemen die vaak voorkomen en steeds weer terugkomen. Na een aantal jaar weet eigenlijk niemand meer precies waarom het op een bepaalde manier is bedacht. De langetermijnstrategie is ver te zoeken en de organisatie gebruikt de software niet, of niet optimaal – omdat de de software niet meer gefocust is op het oorspronkelijke doel. Dit zal iedere IT-manager herkennen. Helaas, want er is al heel lang een oplossing om dit soort problemen te voorkomen!
De oplossing: Domain Driven Design
Deze oplossing is ‘Domain Driven Design’ (DDD), een methode die zorgt voor een veel betere samenwerking tussen de business en developers. Het is namelijk veel effectiever om business en developers samen de software te laten modelleren. Door een gemeenschappelijke taal te spreken en samen na te denken over de vragen ‘Wat is het doel van de applicatie die we willen bouwen?’ en ‘Welk probleem moet de applicatie oplossen? ’. Dan gaan we dát probleem ook daadwerkelijk oplossen.
Hoe begin je? Simpelgezegd komt het hier op neer: je begint altijd met de ‘problem space vs solution space’, die trek je uit elkaar – begin bij het begin. Teken twee rondjes op papier en zet daarin wat het probleem is en waar je een oplossing voor gaat maken. Wat is de toegevoegde waarde van de software die we gaan bouwen? Zet het op papier en verifieer of het klopt alvorens de volgende stap te zetten.
Hieruit komen vervolgens een soort usecase-achtige UML-modellen, waarin je de oplossing verder uitwerkt. Je begint klein en zo ga je steeds een stapje verder. Maar het belangrijkste is dat iedereen – dus de business én de developers – deze modellen snapt. En dat je efficiënt en met volledige focus van probleem naar oplossing gaat. Zo krijg je iets dat precies past bij de wensen. Als je dat dan ook nog eens een op een kan vertalen naar de software? Dan krijg je geweldige software. En dat is waar het uiteindelijk om draait!
Een voorbeeld: software in het ziekenhuis
Laten we weer even teruggaan naar het voorbeeld van de zorginstelling. We zien maar al te vaak dat de eigenschappen voor bijvoorbeeld een kamerreservering gemixt worden met de eigenschappen voor medicijnen. Omdat deze nou eenmaal bij de patiënt horen. Echter bekijk je de software bij DDD niet vanuit de plek waar je deze gegevens opslaat, maar naar gebruik door afdelingen. De afdeling die gaat over de reservering van bedden heeft helemaal niets te maken met het medicijngebruik van een patiënt. Met DDD kijkt men meer vanuit afdelingen en behoeftes, om te voorkomen dat de software een “big ball of mud” wordt.
Vanuit de DDD-visie gaat het hier om het twee probleemdomeinen. Eén domein is patiënten en kamers, het tweede domein is patiënten en medicijnen. Dat zijn twee afdelingen met ieder hun eigen gegevens over een patiënt. DDD maakt hier in de software dan ook een duidelijke scheiding tussen, met twee probleemdomeinen die we helemaal los van elkaar tekenen. Iedere patiënt bestaat zo in de twee verschillende probleemdomeinen, met elk zijn eigenschappen behorend bij dat domein.
Met DDD houd je de zaken dus goed gescheiden en overzichtelijk, zowel aan de business-kant als aan de IT-kant. Hierdoor wordt doorontwikkeling makkelijker met minder technical debt, en is de software duurzamer en van hogere kwaliteit.
Lees je in, lees dit boek
In 2003 bedacht Eric Evans DDD. In het boek ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’ beschrijft hij zowel de strategische kant van softwaredevelopment, alsook de implementatie van de software. Dit boek is zowel de business als voor development geschikt; je werkt toe naar een gezamenlijk proces, en het spreken van dezelfde taal (ubiquitous language).
Wanneer je Domain Driven Design wilt toepassen, is het zaak dat alle teamleden (business én development) zich hebben ingelezen. Het boek van Eric Evans is hier zeer goed voor te gebruiken.
Wil je ook starten met Domain Driven Design? Mijn collega’s en ik komen je graag meer vertellen en kunnen je helpen met het opzetten van de concepten, of het implementeren hiervan. Neem vrijblijvend contact met ons op voor een afspraak.
Heb je vragen over dit onderwerp of zou je één van onze experts willen inhuren voor een vergelijkbare opdracht?
Lees ook onze andere berichten
Heb je een .NET expert nodig?
