Odpowiedź.

Domain-Driven Design (DDD) to podejście do projektowania systemów programowych, które koncentruje się na dziedzinie i jej logice. DDD dzieli złożone dziedzinie na związane, ale niezależne ograniczone konteksty (bounded contexts). W każdym kontekście opracowywany jest swój własny język (Ubiquitous Language), uzgodniony z ekspertami dziedziny. Główne bloczki DDD:

• Entity: obiekt z unikalnym identyfikatorem i cyklem życia (na przykład, zamówienie).
• Value Object: niemienny obiekt bez unikalnego identyfikatora (na przykład, adres dostawy).
• Aggregate & Aggregate Root: zbiór obiektów, dla którego wszystkie zmiany przechodzą przez korzeń agregatu.
• Repository: warstwa do pracy z magazynem agregatów.
• Service: operacje, które nie dotyczą konkretnego obiektu.

Ograniczone konteksty często przedstawiają osobne mikroserwisy, które komunikują się przez wyraźnie opisane API lub zdarzenia.

Przykład kodu w Java (Spring):

// Przykład Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... konstruktory, equals, hashCode
}

// Przykład Entity z Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... metody biznesowe
}

Kluczowe cechy:

• Wyraźna dekompozycja dziedziny i konteneryzacja logiki.
• Uproszczenie rozwoju i skalowania przez izolację.
• Zwiększenie spójności technicznego i biznesowego języka zespołu.

Pytania z podchwytliwością.

Czy wszystkie obiekty w DDD są Entity?

Nie, istnieją również Value Objects — nie mają one unikalności, ich stan w pełni definiuje tożsamość.

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

Czy podział na mikroserwisy oznacza zastosowanie DDD?

Nie, DDD można stosować także w ramach monolitycznej aplikacji, budując wewnętrzne granice kontekstów.

Czy zawsze potrzebny jest repozytorium dla każdego agregatu?

Zazwyczaj tak, ale czasami agregat można całkowicie przechowywać jako część innego agregatu, jeśli nie jest on korzeniem oddzielnej transakcji biznesowej.