Antwoord.

Domain-Driven Design (DDD) is een benadering voor het ontwerpen van softwaresystemen die zich richt op het domein en zijn logica. DDD verdeelt complexe domeinen in gerelateerde, maar onafhankelijke gebonden contexten (bounded contexts). Binnen elke context wordt een eigen taal (Ubiquitous Language) ontwikkeld, afgestemd met domeinexperts. De belangrijkste bouwstenen van DDD:

• Entity: een object met een unieke identifier en levenscyclus (bijvoorbeeld een bestelling).
• Value Object: een onveranderlijk object zonder unieke identifier (bijvoorbeeld een bezorgadres).
• Aggregate & Aggregate Root: een verzameling objecten waar alle veranderingen via de root van de aggregate gaan.
• Repository: een laag voor interactie met de opslag van aggregates.
• Service: operaties die niet aan een specifiek object zijn gerelateerd.

Gebonden contexten zijn vaak afzonderlijke microservices die communiceren via duidelijk beschrijvende API's of gebeurtenissen.

Voorbeeld code in Java (Spring):

// Voorbeeld Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... constructors, equals, hashCode
}

// Voorbeeld Entity met Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... business methods
}

Belangrijke kenmerken:

• Duidelijke decompositie van het domein en containerisatie van logica.
• Vereenvoudiging van ontwikkeling en schaalbaarheid door isolatie.
• Verhoogde consistentie tussen de technische en zakelijke taal van het team.

Vragen met een valstrik.

Zijn alle objecten in DDD Entities?

Nee, er zijn ook Value Objects — zij hebben geen uniciteit, hun toestand bepaalt volledig de identiteit.

Address a1 = new Address("Moskou", "Arbat");
Address a2 = new Address("Moskou", "Arbat");
System.out.println(a1.equals(a2)); // true

Betekent het opsplitsen in microservices de toepassing van DDD?

Nee, je kunt DDD ook toepassen binnen de context van een monolithische applicatie door interne grenzen van contexten op te bouwen.

Is een repository altijd nodig voor elke aggregate?

In de meeste gevallen wel, maar soms kan een aggregate volledig als onderdeel van een andere aggregate worden opgeslagen, als het geen root is van een aparte zakelijke transactie.