Domain Driven Design (DDD): waarom je het nodig hebt

De kern van goed presterende software gaat over meer dan efficiënte code en robuuste integraties. De omgeving waarin de code zijn werk moet doen, het domein, speelt een cruciale rol in het succes. Wat zijn bijvoorbeeld de USP’s van het bedrijf dat de software gaat inzetten? Domain Driven Design (DDD) brengt business en IT dichter bij elkaar en software development wordt gecentraliseerd rondom processen. En hoewel DDD niet direct over technologie gaat, geeft het er dus wel duidelijk richting aan. Je wilt namelijk dat code een afspiegeling is van het domein, zodat software tijdens iedere processtap de flow optimaal faciliteert en software mee kan veranderen als er in de toekomst iets wijzigt in het domein. Domain Driven Design, wat houdt dat precies in en waarom is het nou nuttig om in te zetten?

Domain Driven Design Guild bij ISAAC

DDD begint met de 'Big Picture'

Een krachtige technische oplossing begint met begrip van het grote plaatje. Domain Driven Design zet je in om de domeinen in kaart te brengen. In een ‘Big Picture’-sessie, waar Domain Driven Design gewoonlijk mee begint, brengen domeinexperts uit business en IT alle stappen van een bestaand of een beoogd proces in kaart en werk je aan de common understanding van die processen, variabelen en begrippen. Allereerst is dit een leuke sessie, waarin je actief bezig bent met heel veel sticky notes plakken. Door bedrijfsprocessen te visualiseren met die sticky notes, komen eventuele knelpunten over verschillende ketenonderdelen heen naar de oppervlakte. En omdat je met collega’s van andere domeinen samenwerkt, is het ook heel nuttig op de lange termijn.

"Een specifiek tandwiel functioneert alleen goed als je van tevoren weet hoe de rest van de machine in elkaar zit. Hetzelfde geldt voor software development."

De Big Picture sessie(s) brengen domeinexperts uit de business en developers op één lijn, maar we zien ook vaak dat er nieuwe inzichten ontstaan. Een voorbeeld van een veelvoorkomend vraagstuk in commerce is de integratie tussen een PIM en webshop. Zo heb je te maken met processen rondom PIM-beheer, webshopbeheer en dataverrijking. En dan moeten de data uit de PIM ook nog worden gepubliceerd in de shop. Duidelijke afspraken over welk systeem waar verantwoordelijk voor is, is daarbij een belangrijk onderwerp. Dankzij gesprekken en discussies met alle betrokken domeinexperts komen knelpunten op tafel en wordt er eenduidig begrip gecreëerd van journeys en processen. Software kan daardoor zo worden ontwikkeld dat alle domeinen optimaal worden gefaciliteerd. Je wilt immers een oplossing neerzetten die over de gehele keten goed werkt en niet alleen een specifiek probleem oplost of aan een specifieke behoefte tegemoetkomt.

Wat Domain Driven Design oplevert

Maar hoe levert een Big Picture sessie en Domain Driven Design nou waarde voor software development? Vanuit de rol als development partner, kijken we daar bij ISAAC als volgt tegenaan:

  • Klantervaring op #1: door software te modelleren rondom processen wordt de gebruiker centraal gesteld en creëer je vloeiende digitale journeys.
  • Snellere time-to-market en kostenefficiëntie: tijdens de ontwikkeling loop je altijd tegen vraagstukken en onvoorziene zaken aan. Hoe later je daar tegenaan loopt, hoe kostbaarder het is om bij te sturen. Door met DDD met domeinexperts uit business en IT te sparren over wensen, eisen, processen en journeys, spoor je in een vroeg stadium de meest kritische processen voor het bedrijf op. Door daar in het ontwikkelproces extra aandacht aan te besteden kan er sneller en dus kostenefficiënter worden ontwikkeld.
  • Common understanding: door met alle domeinexperts een eenduidige taal te ontwikkelen, worden zij gesprekspartners en begrijpen beter elkaars uitgangspunten en belangen. Hiermee verdwijnt vaak al een groot deel van de complexiteit van een project.
  • Schaalbare oplossingen: door gezamenlijk businessdoelstellingen, events en eventuele campagnes te bespreken, kan daar op voorhand rekening mee worden gehouden. Systemen kunnen zo worden ingericht om bijvoorbeeld met de Sinterklaas- en Kerstcampagnes goed de piekbelasting aan te kunnen.

Met Domain Driven Design slaan we de brug tussen de business en development, gefocust op toegevoegde waarde. Op voorhand journeys en processen nauwkeurig in kaart brengen en daarover ook eenduidige definities ontwikkelen, is een heel krachtig concept. Hiermee verplaatst de focus van applicatieontwikkeling van een uitgesproken technisch vraagstuk naar de ontwikkeling van functionaliteiten, met de gewenste toegevoegde waarde voor een businessmodel. Dit maakt DDD bij uitstek geschikt is voor complexere digitale uitdagingen, waar vaak ook over de keten heen verschillende domeinen bij betrokken zijn. Met als belangrijkste voordeel dat ontwikkelprocessen (kosten)efficiënter kunnen verlopen.

Innoveren in Guilds

Dit artikel is onderdeel van een reeks artikelen over Guilds bij ISAAC. We geloven dat (techniek)innovatie het beste ontdekt en ontwikkeld kan worden vanuit de werkvloer. De innovatiekracht daarvoor zit bij ons mensen. Collega’s met dezelfde ‘community of interest’ zijn georganiseerd in Guilds, waarvan er op dit moment 16 bij ISAAC draaien. Er zijn onder andere Guilds voor Accessibility, Docker, Java System Integration, Testing, Serverless on AWS en Node.js. Binnen een Guild discussiëren ISAACi over nieuwe technologieën, worden proof-of-concepts ontwikkeld, ervaringen gedeeld of mensen van buitenaf uitgenodigd een training of cursus te verzorgen.

camiel.png
Meer info over DDD?

Wil je meer weten over Domain Driven Design of advies over jouw applicaties? Camiel helpt je graag.

Neem contact op