Wat is Domain Driven Design?
Domain driven design verkleint de afstand tussen je business doelen en IT ondersteuning.
Door je anders te organiseren begrijp je elkaar sneller en beter! Hoe mooi is dat?
Wat is DDD?
Domain Driven Design staat voor een methodologie die verder gaat dan alleen software of systeem ontwerp. Het raakt juist je business. DDD gaat uit van een indeling van je organisatie rondom je business processen én daarmee ook je (software) applicaties. Hoe dat werkt leer je tijdens onze DDD training Basics
De kern van Domain Driven Design
De kern van DDD is de zogenaamde "ubiquitous language". Dat houdt in dat alle betrokkenen in een domein dezelfde taal spreken. Termen als gebruiker, offerte, prijs, klant, etc. betekenen precies hetzelfde voor iedereen in dat domein. In een ander domein kan er een andere definitie worden gegeven aan termen.
Dat is belangrijk omdat er zo geen verwarring ontstaat tussen wat de business bedoelt en wat IT bouwt. Concreet voorbeeld is de verkoopprijs, die in het Sales domein opgebouwd is uit elementen zoals kostprijs, opslagen, etc. terwijl diezelfde verkoopprijs in het Marketing domein niets meer is dan een getal om in een uiting te tonen.
DDD in de praktijk
Domain Driven Design raakt de hele organisatie en dat betekent dat je het invoeren ervan zorgvuldig moet gebeuren. Normaal gesproken begin je aan twee kanten, de business kant en de IT kant van één domein.
Beiden gaan in gesprek om zaken als bounded contexts, aggregates etc. te ontdekken. Analyse van huidige systemen hoort daarbij om te zien of zaken als CQRS (command query responsibility segregation) of Event driven architectuur makkelijk of juist lastiger zijn te integreren.
Rollen binnen DDD
Binnen de DDD methodologie zijn er verschillende rollen: DDD Enabler, Agile Coach, Software Architect, Product Manager of Owner. En natuurlijk de developers in het ontwikkelteam. Leer in onze DDD trainingen meer over wat deze rollen inhouden in de praktijk.
Domain Driven Design, CQRS, Event Storming, Event Sourcing, Bounded Context, Events
Allemaal termen die aan bod komen in onze trainingen. De Basics training gaat vooral over het begrip van deze termen. En in de Next Level training ligt vooral de nadruk op hoe pas je dit toe in je systeem ontwerp en code.
CQRS
Command Query Responsibility Segregation staat de afkorting voor. In het kort houdt het in dat je in je software ontwerp een scheiding aanbrengt in het wegschrijven van gegevens, waar transacties belangrijk zijn om integriteit te waarborgen. En het lezen van gegevens, waar die integriteit al afgehandeld is door het wegschrijven. Dit leidt tot meer autonomie en betere prestaties van je systeem.
Event Storming
Event Storming is een manier om business eigenaren en IT ontwikkelaars samen de oplossing te bedenken voor een business doel. In deze meeting vorm gaan we aan de slag met Events, Business processen en onderkennen waar we belangrijke keuzes moeten maken.
Event Sourcing
Sourcing van events ofwel opslaan en teruglezen van events heeft een groot voordeel: het teruggaan naar een vorige versie van je applicatie is altijd mogelijk omdat je na elke gebeurtenis (event) precies dat opslaat: wat is er veranderd aan mijn systeem en door wat is dat veroorzaakt.
Bounded Context
Een kernbegrip in DDD is bounded context. Dit is het gebied of beter domein waarin dezelfde (business) regels gelden en waarin we de over de gebruikte termen in ons business proces afspreken wat we hier mee bedoelen.
Events
Events of gebeurtenissen zijn belangrijk in een DDD omgeving. Dit zijn de zaken waar we de gedragingen van ons systeem beschrijven. Door het gebruik van Events in een software ontwerp (event driven architectuur) zorg je ook voor meer autonome systemen. En dat helpt weer bij je flexibiliteit als domein en het verkorten van je time-to-market.