Risposta.

Il Domain-Driven Design (DDD) è un approccio alla progettazione di sistemi software che si concentra sul dominio e sulla sua logica. DDD suddivide domini complessi in contesti limitati (bounded contexts) collegati ma indipendenti. All'interno di ciascun contesto viene sviluppato un linguaggio proprio (Ubiquitous Language), concordato con gli esperti del dominio. I principali blocchi costitutivi del DDD:

• Entity: oggetto con un identificatore unico e un ciclo di vita (ad esempio, un ordine).
• Value Object: oggetto immutabile senza identificatore unico (ad esempio, un indirizzo di spedizione).
• Aggregate & Aggregate Root: un insieme di oggetti, per la quale tutte le modifiche passano attraverso la radice dell'aggregato.
• Repository: livello per lavorare con lo storage degli aggregati.
• Service: operazioni che non appartengono a un oggetto specifico.

I contesti limitati rappresentano spesso microservizi separati che interagiscono tramite API o eventi esplicitamente descritti.

Esempio di codice in Java (Spring):

// Esempio di Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... costruttori, equals, hashCode
}

// Esempio di Entity con Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... metodi di business
}

Caratteristiche chiave:

• Chiara decomposizione del dominio e containerizzazione della logica.
• Semplificazione dello sviluppo e della scalabilità grazie all'isolamento.
• Aumento della coerenza tra il linguaggio tecnico e quello di business del team.

Domande trabocchetto.

Tutti gli oggetti nel DDD sono Entity?

No, ci sono anche i Value Objects: non hanno unicità, il loro stato definisce completamente l'identità.

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

Significa che suddividere in microservizi applica DDD?

No, è possibile applicare DDD anche all'interno di un'applicazione monolitica, costruendo confini interni dei contesti.

È sempre necessario un repository per ogni aggregato?

Di solito sì, ma a volte un aggregato può essere completamente memorizzato come parte di un altro aggregato, se non è la radice di una transazione di business separata.