Leestijd
Vrijwel iedere organisatie zegt tegenwoordig productgedreven te werken. Er wordt geïnvesteerd in Agile, multidisciplinaire teams en kortere ontwikkelcycli. Product Owners krijgen meer verantwoordelijkheid, architectuur verschuift richting de teams en organisaties proberen sneller in te spelen op veranderingen in de markt. Op papier lijkt daarmee aan alle voorwaarden voor succesvolle productontwikkeling te zijn voldaan.
Toch ervaren veel organisaties het tegenovergestelde. Naarmate het aantal teams groeit, neemt de complexiteit toe. Besluiten kosten meer tijd, afhankelijkheden stapelen zich op en producten ontwikkelen zich minder voorspelbaar dan gehoopt. Nieuwe functionaliteit blijkt onverwachte gevolgen te hebben voor andere systemen, teams voeren dezelfde discussies steeds opnieuw en de samenwerking tussen business en technologie vraagt steeds meer afstemming.
De reflex is vaak om de oorzaak in techniek te zoeken. Organisaties investeren in nieuwe platformen, moderniseren hun architectuur of introduceren een nieuw framework. Hoewel dergelijke initiatieven waardevol kunnen zijn, lossen ze zelden het onderliggende probleem op. In veel gevallen ontstaat de complexiteit namelijk niet door de technologie zelf, maar door de manier waarop de organisatie haar eigen werkelijkheid begrijpt.
Dat klinkt abstract, maar wordt dagelijks zichtbaar in de praktijk. Een afdeling spreekt over klanten, terwijl een andere afdeling eigenlijk contracthouders bedoelt. Productmanagement prioriteert op basis van klantwaarde, terwijl Finance stuurt op kostenplaatsen en IT uitgaat van de structuur van bestaande applicaties. Iedereen gebruikt dezelfde woorden, maar bedoelt iets anders. Pas wanneer meerdere teams gezamenlijk aan dezelfde waardestroom werken, wordt duidelijk hoeveel interpretatieverschillen er eigenlijk bestaan.
Juist daar ligt de kracht van Domain-Driven Design, kortweg DDD. Hoewel het vaak wordt gepresenteerd als een methode voor softwareontwikkeling, is het in de kern een manier om organisaties weer vanuit dezelfde werkelijkheid te laten samenwerken. Het uitgangspunt is verrassend eenvoudig: voordat je systemen ontwerpt, moet je eerst gezamenlijk begrijpen hoe de organisatie daadwerkelijk werkt. Pas wanneer daar overeenstemming over bestaat, kunnen producten en software die werkelijkheid op een consistente manier ondersteunen.
Toen Eric Evans in 2003 zijn boek Domain-Driven Design publiceerde, lag de nadruk vooral op complexe bedrijfssoftware. Inmiddels is de context sterk veranderd. Vrijwel iedere organisatie ontwikkelt digitale producten en vrijwel iedere organisatie heeft meerdere teams die tegelijkertijd aan verschillende onderdelen van hetzelfde landschap werken. Wat ooit vooral een uitdaging was voor softwarebedrijven, is inmiddels een vraagstuk geworden voor banken, overheden, zorginstellingen, retailers en industriële ondernemingen.
Die ontwikkeling heeft ook de rol van software veranderd. Applicaties ondersteunen niet langer slechts bedrijfsprocessen; ze vormen steeds vaker het product zelf. Dat betekent dat beslissingen over technologie, productontwikkeling en bedrijfsvoering voortdurend met elkaar verweven zijn. Een wijziging in een digitaal product heeft directe gevolgen voor klanten, interne processen en soms zelfs het verdienmodel van een organisatie.
Juist daardoor wordt de kwaliteit van samenwerking belangrijker dan ooit. Niet alleen tussen ontwikkelaars onderling, maar vooral tussen productmanagement, business, architectuur en de mensen die dagelijks met klanten werken. Wanneer die disciplines ieder een ander beeld hebben van het domein waarin zij opereren, ontstaat een vorm van complexiteit die zich moeilijk laat oplossen met technische maatregelen alleen.
Dat is zichtbaar in vrijwel iedere grote organisatie. Productteams ontwikkelen oplossingen die technisch uitstekend functioneren, maar onvoldoende aansluiten op de dagelijkse praktijk van gebruikers. Business formuleert wensen die logisch klinken vanuit het eigen proces, maar nauwelijks uitvoerbaar blijken binnen de bestaande producten. Architecten proberen samenhang aan te brengen in een landschap dat ondertussen voortdurend verandert. Ondertussen groeit de hoeveelheid overleg, documentatie en governance, terwijl de besluitvorming juist trager wordt.
Opvallend genoeg wordt die vertraging vaak geaccepteerd als een logisch gevolg van schaalgrootte. Grote organisaties zijn nu eenmaal complex, zo luidt de redenering. Toch is dat slechts een deel van het verhaal. Natuurlijk neemt de technische complexiteit toe wanneer tientallen teams samenwerken aan honderden applicaties. Maar minstens zo belangrijk is de vraag of al die teams dezelfde werkelijkheid voor ogen hebben. Zonder een gedeeld begrip van het domein ontstaat onvermijdelijk interpretatieverschil, en juist dat vormt vaak de grootste bron van vertraging.
Binnen Domain-Driven Design neemt de zogenoemde Ubiquitous Language een centrale plaats in. Letterlijk betekent dit een alomtegenwoordige taal: een verzameling begrippen die door iedereen binnen een bepaald domein op dezelfde manier wordt gebruikt. Dat lijkt op het eerste gezicht een kwestie van terminologie, maar de impact is veel groter.
In veel organisaties ontwikkelen afdelingen in de loop der jaren hun eigen taal. Dat gebeurt meestal onbewust. Finance kijkt naar financiële entiteiten, marketing naar doelgroepen, operations naar processen en softwareteams naar objecten en databases. Iedere discipline bouwt daarmee een eigen werkelijkheid op die logisch is binnen de eigen context, maar niet noodzakelijk aansluit op de werkelijkheid van anderen.
Zolang deze werelden grotendeels los van elkaar functioneren, levert dat weinig problemen op. De situatie verandert zodra multidisciplinaire teams gezamenlijk verantwoordelijk worden voor een product of waardestroom. Ineens blijken ogenschijnlijk eenvoudige begrippen verschillende betekenissen te hebben. Een bestelling is voor de logistieke afdeling iets anders dan voor Finance. Een abonnement betekent voor de commerciële organisatie iets anders dan voor het facturatiesysteem. Zelfs het begrip ‘klant’ kent binnen veel organisaties meerdere definities.
Dat soort verschillen lijkt misschien onschuldig, maar heeft grote gevolgen voor de ontwikkeling van producten. Ontwikkelaars bouwen software op basis van begrippen die later anders blijken te worden geïnterpreteerd. Productmanagers prioriteren functionaliteit vanuit aannames die niet door iedereen worden gedeeld. Architecten proberen systemen logisch op te delen, terwijl de organisatie zelf het onderliggende domein nog niet eenduidig heeft beschreven.
Het gevolg is herkenbaar. Teams besteden een groot deel van hun tijd aan het verduidelijken van eerder gemaakte afspraken. Requirements moeten worden aangepast, processen opnieuw ontworpen en software uitgebreid met uitzonderingen die eigenlijk nooit nodig hadden hoeven zijn. De technische schuld die daardoor ontstaat, begint vaak niet in de code, maar veel eerder in de taal waarmee organisaties hun eigen werkelijkheid beschrijven.
Daarom draait Domain-Driven Design niet in de eerste plaats om softwarepatronen of architectuurmodellen. Het begint met gesprekken. Gesprekken waarin business, productmanagement, architectuur en development gezamenlijk onderzoeken hoe een organisatie werkelijk functioneert. Niet hoe processen ooit zijn ontworpen of hoe applicaties vandaag zijn ingericht, maar hoe waarde daadwerkelijk ontstaat voor klanten en welke begrippen daarbij horen.
Juist dat maakt DDD verrassend actueel. Moderne productorganisaties investeren veel in autonomie. Teams krijgen ruimte om zelfstandig beslissingen te nemen en verantwoordelijkheid te dragen voor hun eigen producten. Maar autonomie werkt alleen wanneer iedereen dezelfde uitgangspunten deelt. Een team kan pas zelfstandig goede keuzes maken wanneer duidelijk is binnen welk domein het opereert, welke taal daarbij hoort en welke verantwoordelijkheid het werkelijk draagt.
Wie voor het eerst met Domain-Driven Design in aanraking komt, krijgt vaak de indruk dat het vooral een discipline voor softwareontwikkelaars is. Begrippen als Aggregates, Entities, Value Objects en Repositories domineren veel boeken, presentaties en trainingen. Daardoor ontstaat gemakkelijk het beeld dat DDD pas relevant wordt zodra de technische architectuur wordt ontworpen.
In de praktijk blijkt het tegenovergestelde waar. De organisaties die het meeste profijt hebben van Domain-Driven Design zijn vaak organisaties die eerst investeren in het begrijpen van hun business en pas daarna nadenken over software. Zij gebruiken DDD niet als ontwerpmethode voor code, maar als hulpmiddel om productontwikkeling, bedrijfsprocessen en technologie dichter bij elkaar te brengen.
Dat vraagt een andere manier van kijken naar productontwikkeling. Niet de applicatie staat centraal, maar het probleem dat een organisatie probeert op te lossen. Niet de organisatiestructuur bepaalt hoe software wordt opgebouwd, maar de logica van het domein zelf. Daardoor verschuift de aandacht van systemen naar producten en van functies naar waardecreatie.
Die verschuiving sluit opvallend goed aan bij de ontwikkeling die veel organisaties de afgelopen jaren hebben doorgemaakt. Productdenken, waardestromen en multidisciplinaire teams zijn inmiddels voor veel organisaties bekende begrippen. Toch blijkt in de praktijk dat teams nog regelmatig worden georganiseerd rondom bestaande applicaties of afdelingen. Daardoor ontstaan afhankelijkheden die weinig met klantwaarde te maken hebben, maar vooral voortkomen uit historische keuzes.
Domain-Driven Design biedt een alternatief perspectief. In plaats van bestaande systemen als uitgangspunt te nemen, kijkt DDD eerst naar de logische samenhang binnen het domein. Welke problemen horen daadwerkelijk bij elkaar? Waar ontstaan beslissingen? Welke verantwoordelijkheden zijn logisch te combineren en waar lopen verschillende werkelijkheden juist uiteen? Dat lijken eenvoudige vragen, maar de antwoorden vormen vaak de basis voor een veel effectievere inrichting van producten én teams.
Dat brengt ons bij een van de bekendste concepten binnen Domain-Driven Design: de Bounded Context. Hoewel dit begrip vaak technisch wordt uitgelegd, is het in de praktijk vooral een organisatiekundig principe. Een Bounded Context beschrijft een afgebakend deel van de organisatie waarin begrippen een eenduidige betekenis hebben en waarin duidelijk is welke regels, processen en verantwoordelijkheden gelden. Buiten die context kan dezelfde term iets anders betekenen, zonder dat dit direct een probleem hoeft te zijn.
Juist dat inzicht helpt veel organisaties vooruit. Er is namelijk geen enkele reden waarom een begrip als ‘klant’ overal exact dezelfde betekenis moet hebben. Voor een marketingteam is een prospect immers iets anders dan voor de financiële administratie, terwijl een serviceteam weer naar een heel andere werkelijkheid kijkt. Problemen ontstaan pas wanneer organisaties verwachten dat al deze perspectieven in één universeel model passen. In de praktijk leidt dat vaak tot ingewikkelde datastructuren, eindeloze discussies en software die steeds moeilijker te onderhouden is.
Door domeinen bewust af te bakenen, ontstaat ruimte voor eenvoud. Teams krijgen een duidelijk verantwoordelijkheidsgebied, besluitvorming kan dichter bij het team plaatsvinden en afhankelijkheden worden zichtbaar voordat ze de voortgang belemmeren. Daarmee raakt Domain-Driven Design direct aan onderwerpen als Team Topologies, platformdenken en moderne productorganisaties. Niet omdat deze methoden hetzelfde zijn, maar omdat ze allemaal vertrekken vanuit dezelfde gedachte: organiseer teams rondom een logisch afgebakend probleemgebied in plaats van rondom technologie of organisatiestructuren.
Dat betekent overigens niet dat ieder productteam volledig zelfstandig kan opereren. Moderne organisaties blijven afhankelijk van samenwerking tussen domeinen. Juist daarom besteedt Domain-Driven Design veel aandacht aan de relaties tussen verschillende contexten. Niet alle teams hoeven dezelfde taal te spreken, zolang maar duidelijk is waar de grenzen liggen en hoe informatie tussen domeinen wordt uitgewisseld. Die helderheid voorkomt dat iedere wijziging direct gevolgen heeft voor tientallen andere teams.
In de praktijk blijkt dat een belangrijk verschil met veel traditionele organisatieontwerpen. Daar wordt samenwerking vaak georganiseerd door extra overlegstructuren, governance of centrale besluitvorming. Domain-Driven Design kiest een andere route. Hoe duidelijker de grenzen van een domein zijn, hoe minder afstemming er nodig is. Niet omdat teams minder samenwerken, maar omdat de aard van die samenwerking verandert. Gesprekken gaan niet langer over interpretaties van begrippen, maar over de waarde die verschillende domeinen gezamenlijk creëren.
Domain-Driven Design wordt nog regelmatig gezien als een discipline voor softwareontwikkelaars. In moderne productorganisaties is dat beeld achterhaald. Juist Product Managers, architecten en businessvertegenwoordigers spelen een cruciale rol bij het ontwikkelen van een gedeeld begrip van het domein.
Voor Product Managers betekent dit dat hun rol verder gaat dan het beheren van een backlog of het prioriteren van functionaliteit. Zij moeten begrijpen hoe een organisatie waarde creëert, welke bedrijfsregels bepalend zijn en waar verschillende belangen samenkomen. Dat vraagt om intensieve samenwerking met domeinexperts, gebruikers en ontwikkelteams. Hoe beter dat gezamenlijke begrip wordt, hoe eenvoudiger het wordt om keuzes te maken die zowel technisch als bedrijfsmatig houdbaar zijn.
Ook architectuur krijgt binnen Domain-Driven Design een andere positie. Waar architecten vroeger complete systeemlandschappen ontwierpen, verschuift hun rol steeds vaker naar het bewaken van de samenhang tussen domeinen. Zij helpen teams logische grenzen te herkennen, ondersteunen bij integratievraagstukken en zorgen ervoor dat lokale optimalisaties niet ten koste gaan van het grotere geheel.
Hetzelfde geldt voor softwareontwikkeling. Goede ontwikkelaars bouwen niet alleen technisch hoogwaardige oplossingen, maar investeren ook in het begrijpen van het domein waarvoor zij software ontwikkelen. Dat vraagt om veel directer contact met productmanagement en business dan in traditionele projectorganisaties gebruikelijk was. De kwaliteit van de software wordt uiteindelijk niet alleen bepaald door de code, maar vooral door de kwaliteit van de gesprekken die eraan voorafgaan.
Een techniek die binnen Domain-Driven Design veel wordt gebruikt, is Event Storming. Tijdens zo’n sessie brengen mensen uit verschillende disciplines gezamenlijk in kaart welke gebeurtenissen zich binnen een domein afspelen. Opvallend genoeg zit de grootste waarde meestal niet in het eindresultaat, maar in de gesprekken die onderweg ontstaan. Teams ontdekken dat zij verschillende aannames hanteren, processen anders interpreteren of verantwoordelijkheden heel anders zien dan collega’s uit een andere discipline.
Juist daarom is Event Storming veel meer dan een workshoptechniek. Het is een manier om collectieve kennis zichtbaar te maken voordat technische keuzes worden gemaakt. Veel organisaties slaan die stap over. Zij beginnen met user stories, procesmodellen of architectuurdiagrammen, terwijl nog onvoldoende duidelijk is hoe het domein daadwerkelijk functioneert.
Die valkuil komt vaker voor dan veel organisaties beseffen. Onder druk van deadlines ontstaat al snel de neiging om direct oplossingen te ontwikkelen. Nieuwe functionaliteit wordt gebouwd, processen worden geautomatiseerd en systemen uitgebreid, terwijl fundamentele vragen over begrippen, verantwoordelijkheden en domeingrenzen onbeantwoord blijven. Op korte termijn lijkt dat efficiënt, maar op langere termijn ontstaat een landschap waarin iedere wijziging onverwachte gevolgen heeft.
Dat is ook de reden waarom veel organisaties pas met Domain-Driven Design aan de slag gaan wanneer de complexiteit al hoog is opgelopen. Teams wachten voortdurend op elkaar, eigenaarschap is onduidelijk en de snelheid waarmee producten zich ontwikkelen neemt af. Vaak wordt dan gezocht naar een nieuw framework of een reorganisatie, terwijl de oorzaak veel dieper ligt. Zolang verschillende delen van de organisatie een andere werkelijkheid hanteren, zal iedere nieuwe structuur uiteindelijk tegen dezelfde grenzen aanlopen.
Misschien is dat wel de belangrijkste les van Domain-Driven Design. Het biedt geen blauwdruk voor hoe een organisatie eruit moet zien en schrijft ook niet voor hoe software precies ontwikkeld moet worden. De kracht zit in het gezamenlijk begrijpen van het domein voordat processen, producten of systemen worden ontworpen. Organisaties die daarin investeren, ontdekken vaak dat veel technische problemen in werkelijkheid organisatievraagstukken zijn.
Dat maakt Domain-Driven Design relevanter dan ooit. Moderne productorganisaties werken met autonome teams, waardestromen, platformen en steeds vaker ook kunstmatige intelligentie. Technologie ontwikkelt zich in hoog tempo, maar juist daardoor wordt een gedeeld begrip van het domein steeds belangrijker. Zonder die gezamenlijke basis neemt de complexiteit sneller toe dan de organisatie kan bijbenen.
Ruim twintig jaar na de introductie blijkt de centrale gedachte achter Domain-Driven Design daarom nog altijd verrassend actueel. Niet de techniek bepaalt uiteindelijk het succes van een productorganisatie, maar de mate waarin mensen dezelfde werkelijkheid delen. Wie daarin investeert, ontwikkelt niet alleen betere software, maar bouwt vooral een organisatie waarin productmanagement, business en technologie elkaar daadwerkelijk versterken.
Bekijk de training Domain Driven Design For Productmanagement
Artikel delen
Dass Product Owners eine Zertifizierung absolvieren, ist in vielen Organisationen längst selbstverständlich. Scrum, SAFe und andere agile Methoden sind weit
Von Nico Schellingerhout und Jeroen Jan Elzinga Agile. Ein Begriff, der einst Transformation versprach – und heute oft nur noch
Eine Zusammenfassung des Webinars: Strategisches Portfolio Management – was Organisationen von den VCs aus Silicon Valley lernen können. Vom 17.
Veränderung muss weder schwer noch kompliziert sein. Mit dem richtigen Fokus, Energie und der passenden Begleitung entstehen Klarheit, Richtung und Ergebnisse.
Wir denken gerne mit dir mit.
