DDD

2020-12-22

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

 

Werken bij Infiniot?

Heeft deze blog jou geïnspireerd om ook een bijdrage te leveren aan de energietransitie in Nederland? Goed nieuws! We zijn altijd op zoek naar nieuwe collega’s om ons team te versterken! Bekijk hier onze vacature Software Engineer.


Bekijk alle posts van Eltjon