Antwort.

Domain-Driven Design (DDD) ist ein Ansatz zur Gestaltung von Softwaresystemen, der sich auf das Fachgebiet und dessen Logik konzentriert. DDD zerlegt komplexe Fachgebiete in verwandte, aber unabhängige begrenzte Kontexte (bounded contexts). In jedem Kontext wird eine eigene Sprache (Ubiquitous Language) entwickelt, die mit den Fachexperten abgestimmt ist. Die Hauptbausteine von DDD:

• Entity: Ein Objekt mit einer eindeutigen Identifikation und einem Lebenszyklus (zum Beispiel eine Bestellung).
• Value Object: Ein unveränderliches Objekt ohne eindeutige Identifikation (zum Beispiel eine Lieferadresse).
• Aggregate & Aggregate Root: Eine Ansammlung von Objekten, bei denen alle Änderungen über die Wurzel des Aggregats laufen.
• Repository: Eine Schicht zur Arbeit mit dem Speichersystem von Aggregaten.
• Service: Operationen, die nicht mit einem bestimmten Objekt verbunden sind.

Begrenzte Kontexte stellen oft separate Mikrodienste dar, die über klar beschriebene APIs oder Ereignisse miteinander interagieren.

Beispielcode in Java (Spring):

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

// Beispiel Entity mit Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... Geschäftslogik
}

Wichtige Merkmale:

• Klare Dekomposition des Fachgebiets und Containerisierung der Logik.
• Vereinfachung der Entwicklung und Skalierung durch Isolation.
• Verbesserung der Kohärenz zwischen technischem und geschäftlichem Jargon des Teams.

Trickfragen.

Sind alle Objekte in DDD Entities?

Nein, es gibt auch Value Objects – diese haben keine Einzigartigkeit, ihr Zustand bestimmt vollständig die Identität.

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

Bedeutet die Zerlegung in Mikrodienste die Anwendung von DDD?

Nein, man kann DDD auch innerhalb einer monolithischen Anwendung anwenden, indem man interne Kontextgrenzen aufbaut.

Braucht man immer ein Repository für jedes Aggregat?

Normalerweise ja, aber manchmal kann ein Aggregat vollständig als Teil eines anderen Aggregats gespeichert werden, wenn es nicht die Wurzel einer separaten Geschäftstransaktion ist.