Hoe Domain-Driven Design waarde oplevert voor de business

Engineers drukken de waarde van Domain-Driven Design (DDD) vaak uit in termen van engineering, en niet in termen van waarde voor de business.

In tegenstelling tot grafisch ontwerp of user experience design is softwareontwerp onzichtbaar. Dat maakt het moeilijk om de waarde ervan te begrijpen.

Als bedrijfsleider ben je misschien niet bijzonder geïnteresseerd in de eigenaardigheden van DDD: hoe je een gedeelde taal bouwt, of hoe je domeinmodellen organiseert in bounded contexts. Het is niet dat dit werk geen waarde oplevert voor de business, integendeel, maar we drukken zelden uit welke waarde het kan opleveren voor de business en haar doelen. Dat staat uiteindelijk de adoptie in de weg van DDD en van de ontwerptechnieken waarvan we geloven dat ze organisaties kunnen helpen succesvol te zijn.

Natuurlijk, als een softwaresysteem beter geëngineerd is met behulp van DDD, zullen engineers productiever zijn bij de ontwikkeling ervan, wat uiteindelijk gunstig is voor de organisatie. Maar er zijn directere manieren waarop DDD waarde oplevert voor de business. We lichten hier enkele voorbeelden uit.

DDD richt de ontwerpinspanning op bedrijfsdoelen op lange termijn

DDD is een diep pragmatische discipline. Ze erkent dat ontwerpinspanning een beperkte hulpbron is die gepast ingezet moet worden. DDD legt geen harde regels op om alles tot in de perfectie te engineeren. In plaats daarvan zegt het: laten we investeren in beter ontwerp waar we geloven dat het voordelig is. Als we bijvoorbeeld ontdekken dat een nieuwe component in de toekomst niet veel zal veranderen, investeren we niet in een verfijnder domeinmodel met meer flexibiliteit. In plaats daarvan gaat die ontwerpinspanning naar iets dat er meer baat bij heeft, zoals een "Core domain" (een bedrijfsactiviteit die echt het verschil maakt). Veel andere softwareontwerpdisciplines behandelen alle software gelijk en streven overal naar een perfect ontwerp, zonder de bredere context van die component te begrijpen.

Wanneer je iets wil bouwen dat lang productief blijft, is die focus op ontwerp ongelooflijk nuttig. Een goed ontworpen systeem (voor een niet-triviaal bedrijfsdomein) blijft onderhoudbaar, begrijpelijk, testbaar en vooral evolueerbaar zolang als nodig. Bij veel softwareprojecten vertraagt het tempo van oplevering na 3 tot 6 maanden. Dat is een rechtstreeks gevolg van slecht ontwerp: mensen begrijpen het web van verbindingen niet meer, dat ze zelf creëerden door lukraak features toe te voegen. DDD pleit ervoor om modellen te bouwen als deel van het engineeringwerk, en die modellen te laten evolueren naarmate nieuwe feature requests binnenkomen. Die modellen zijn de sleutel tot begrijpelijkheid en dus tot evolueerbaarheid.

DDD-beoefenaars bouwen modellen op basis van een diep begrip van de noden van de business. Ze zien zichzelf als hoeders van de relatie tussen de bedrijfsdoelen en het softwaresysteem. Als systeemontwerpers kijken we van dichtbij naar de doelen van de business. De modellen, en dus het systeem, zijn niet alleen ontworpen om snel features op te leveren, maar om die langetermijndoelen te halen. We verdelen de ontwerpinspanning volgens de verwachte impact.

DDD vertaalt bedrijfsstrategie naar softwarestrategie

Een kernbelofte van Domain-Driven Design is het vermogen om bedrijfsstrategie te vertalen naar softwarestrategie.

We houden van het adagium "De oudste code in je systeem zou je beste code moeten zijn." Mensen zijn verrast door die uitspraak: vaak is de oudste code de slechtste, meest fragiele code in het systeem. Maar als je bedrijf erkent dat zijn kernactiviteit afhangt van zijn oudste code, dan betekent goed softwareontwerp en goede strategie dat je de meeste inspanning en de beste mensen inzet om ervoor te zorgen dat de legacy-code schoon, goed gemodelleerd en begrepen is.

Het antwoord van softwareteams op een bedrijfsstrategie is echter niet altijd technische excellentie en marginale verbeteringen. Wanneer de business beslist heeft om een productlijn stop te zetten of de focus te verleggen naar een ander aanbod, zou goed softwareontwerp en goede strategie niet blijven investeren in codebases die geen grote impact zullen hebben. Als je bedrijf actief is in, pakweg, B2B-retail, dan zal een betere zelfgemaakte tool om PDF's te genereren geen verschil maken voor de winst. Een goed ontworpen prijsengine die zich kan aanpassen aan de marktomstandigheden wel.

Bounded contexts maken snel experimenteren mogelijk

Een bounded context is een grens rond een model en zijn taal. DDD-beoefenaars identificeren die grenzen om grote, complexe omgevingen beheersbaar te maken. In plaats van één model te bouwen dat de hele business omvat, identificeren ze gebieden die geïsoleerd kunnen worden. Zo kan de softwareontwerper redeneren over een kleiner stuk van de business, en het laten evolueren zonder de rest van het softwaresysteem te raken.

Bounded contexts (BC's) helpen ons complexiteit te isoleren. Laten we bij het voorbeeld van de prijsengine blijven. We zouden het hele prijsdomein als één concept kunnen modelleren. Maar bij nader inzien zouden we kunnen beslissen om de functionaliteit voor leveranciersprijzen en marges te scheiden van de functionaliteit om onze prijzen te positioneren tegenover die van concurrenten. De BC voor marges zal vrij stabiel zijn: de percentages kunnen veranderen, maar het idee van marges bovenop leveranciersprijzen zetten zal uiteindelijk niet veranderen.

De manier waarop we reageren op de prijzen van concurrenten kan wel sterk veranderen. We zullen ons moeten aanpassen aan nieuwe concurrenten, nieuwe manieren moeten bouwen om prijzen te scrapen, reageren op campagnes… We zullen wellicht experimenteren met verschillende strategieën: voor sommige productcategorieën zouden we ons bijvoorbeeld kunnen positioneren als de premiumaanbieder, en onze prijzen boven die van de concurrentie houden.

Later willen we misschien nieuwe mogelijkheden toevoegen aan onze prijsengine, zoals prijsexperimenten uitvoeren om het ideale prijspunt voor een product te leren kennen. Ook hier kunnen we het model (samen met zijn logica, regels en taal) afsplitsen in een aparte bounded context:

Door het te scheiden van de andere verantwoordelijkheden zijn we veel vrijer om te experimenteren met deze bounded context. We zouden het model vaak kunnen veranderen en uitzoeken wat de beste aanpak is, zonder te moeten omgaan met de complexiteit van de andere bounded contexts. Die vrijheid helpt ons om snel het beste ontwerp te vinden, het ontwerp dat het best past bij de noden van de business.

Een goed model van je systeem stelt je dus in staat om snel te bewegen. En een goed model helpt je voorspellingen te doen over het gedrag van het systeem, en over hoe het systeem zich in de toekomst zal gedragen. En als je dingen snel kan veranderen, kan je dingen snel laten evolueren. Je kan snel experimenteren. Je kan snel innoveren. Je kan veranderingen in de markt voorblijven en je doelen bereiken.