Domain-Driven Design (DDD)

Veel mensen in de software-industrie komen ooit de term Domain-Driven Design [DDD] tegen. DDD heeft strategische waarde. Veel bedrijven met een complex domein vertrouwen erop om software te produceren die mee kan evolueren met het bedrijf. Het fundamentele principe van DDD is “ubiquitous language“, wat een verkorte manier is om te stellen dat domeinterminologie overal moet worden gebruikt, het moet alomtegenwoordig zijn.

DDD-meetups worden jaarlijks gehouden in verschillende plaatsen, waaronder Amsterdam (momenteel alleen online).

Domain-driven design is de praktijk van het ontwerpen van een project volgens de domeinen die het raakt.

Wat is het domein?

Om domain-driven design te definiëren, moet er eerst vastgesteld worden wat met domein wordt bedoeld. Bij softwareontwikkeling wordt het domein gedefinieerd als het vakgebied waarop de applicatie van toepassing is. Een andere veelgebruikte term tijdens softwareontwikkeling is de domain layer of domain logic of business logic. De business logic van een applicatie verwijst naar de regels op een hoger niveau voor hoe bedrijfsobjecten met elkaar omgaan om gemodelleerde gegevens te maken en te wijzigen.

Wat is Domain-Driven Design

Domain-driven design is geïntroduceerd en populair gemaakt door programmeur Eric Evans in zijn boek van 2004: Domain-Driven Design: Tackling Complexity in the Heart of Software. Het is bedoeld om het creëren van applicaties in complexe domeinen makkelijker te maken en richt zich op vier kernprincipes:

  • Context – De setting waarin een woord  zijn betekenis krijgt.
  • Model – Een systeem van abstracties dat geselecteerde aspecten van een domein beschrijft.
  • Ubiquitous Language – Een taal gestructureerd rond het domeinmodel en gebruikt door alle teamleden om alle activiteiten van het team met de software te verbinden.
  • Bounded Context – Een beschrijving van de grens waarbinnen een bepaald model wordt gedefinieerd.

 

Building Blocks

Domain-driven design maakt gebruik van een aantal concepten om domeinmodellen te creëren.

  • Entity – Een object dat niet wordt bepaald door zijn attributen, maar door een draad van continuïteit en zijn identiteit.
  • Value Object – Een onveranderlijk object dat attributen heeft, maar geen duidelijke identiteit.
  • Domain Event – Een domeinevenement is een evenement waar domeinexperts om geven.
  • Aggregate – Een verzameling van objecten die met elkaar zijn verbonden door een hoofdentiteit, bekend als een aggregate root. De aggregate root garandeert de consistentie van wijzigingen die worden aangebracht binnen het aggregaat door externe objecten te verbieden verwijzingen naar zijn leden te bevatten.
  • Service – Een service is een vorm van business logic die behoort conceptueel niet tot enig object. Met andere woorden, als een bepaalde functionaliteit moet bestaan, maar deze niet kan worden gerelateerd aan een entiteit of value object, is het waarschijnlijk een service.
  • Repositories  – In DDD een repository is een service die een globale interface gebruikt om toegang te bieden tot alle entiteiten en value objecten die zich binnen een bepaalde geaggregeerde collection bevinden.
  • Factory – Methoden voor het maken van domeinobjecten

 

Voordelen van Domain-Driven Design

  • Maakt communicatie makkelijker – Door een gemeenschappelijke taal vast te stellen met betrekking tot de domeinen, vinden teams communicatie veel gemakkelijker.
  • Verbetert flexibiliteit – DDD is gebaseerd op de concepten van Object Oriented Design, aangezien bijna alles binnen het domeinmodel is gebaseerd op een object. Hierdoor kunnen verschillende componenten modulair en ingekapseld worden en regelmatig worden gewijzigd.
  • Benadrukt Domain Over Interface – Omdat DDD bouwt rond de concepten van het domein en wat de domeinexperts adviseren, produceert DDD applicaties die representatief zijn voor het domein, in tegenstelling tot die applicaties die eerst de UI / UX benadrukken.

 

Nadelen van Domain-Driven Design

  • Vereist robuuste domeinexpertise – Zelfs met de technisch meest bekwame ontwikkelaars die aan een project werken, moet er ten minste één domeinexpert in het team zijn die de exacte ins en outs van het vakgebied kent.
  • Maakt gebruik van iteratieve praktijken – DDD vertrouwt op constante iteraties. Sommige organisaties hebben mogelijk moeite met deze praktijken, vooral als hun ervaringen verband zijn met minder flexibele ontwikkelingsmodellen, zoals het watervalmodel. Soms wordt dit als een voordeel beschouwd.

 

Verder leren

  • Domain-Driven Design, boek van Eric Evans
  • Implementing Domain Driven Design, boek van Vaughn Vernon
  • Domain-Driven Design Europe, youtube channel
No data was found

Veel mensen in de software-industrie komen ooit de term Domain-Driven Design [DDD] tegen. DDD heeft strategische waarde. Veel bedrijven met een complex domein vertrouwen erop om software te produceren die mee kan evolueren met het bedrijf. Het fundamentele principe van DDD is “ubiquitous language“, wat een verkorte manier is om te stellen dat domeinterminologie overal moet worden gebruikt, het moet alomtegenwoordig zijn.

No data was found

Dit artikel delen

Bekijk ook deze artikelen

Het probleem en de wens Het doel van CI/CD is om zoveel mogelijk werk uit de handen van het team te nemen: het stukje CI test en valideert de code,...
– Wat is diabetes “type 1” ook alweer? Diabetes type 1 wordt gekenmerkt door een gebrek aan insulineproductie door de alvleesklier. In de meeste gevallen wordt dit veroorzaakt door een...
Er draait echter wel een stevige energiecentrale voor. Met de toename van AI-gebruik, stijgen ook de zorgen over de impact op het klimaat. Rekenen kost nu eenmaal energie, en AI...

Samen met ons bouwen aan een duurzame toekomst? Neem contact op!

Maak impact. Samen. Jij ook?

"*" geeft vereiste velden aan

Privacyverklaring*
Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.

×

Welkom bij Infiniot! Wij helpen je graag verder op weg.

× Stel hier jouw vraag