Réponse.

Le Domain-Driven Design (DDD) est une approche de conception des systèmes logiciels qui se concentre sur le domaine métier et sa logique. DDD décompose des domaines métier complexes en contextes limités (bounded contexts) liés mais indépendants. Dans chaque contexte, un langage propre (Ubiquitous Language) est développé, en accord avec les experts du domaine. Les principaux blocs de construction du DDD :

• Entity : un objet avec un identifiant unique et un cycle de vie (par exemple, une commande).
• Value Object : un objet immuable sans identifiant unique (par exemple, une adresse de livraison).
• Aggregate & Aggregate Root : un ensemble d'objets pour lequel toutes les modifications passent par la racine de l'agrégat.
• Repository : une couche pour travailler avec le stockage des agrégats.
• Service : des opérations qui ne sont pas liées à un objet spécifique.

Les contextes limités représentent souvent des microservices distincts interagissant via des API ou des événements clairement décrits.

Exemple de code en Java (Spring) :

// Exemple de Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... constructeurs, equals, hashCode
}

// Exemple d'Entity avec Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... méthodes métier
}

Caractéristiques clés :

• Décomposition claire du domaine métier et conteneurisation de la logique.
• Simplification du développement et de l'évolutivité grâce à l'isolation.
• Amélioration de la cohérence entre le langage technique et le langage métier de l'équipe.

Questions pièges.

Tous les objets dans le DDD sont-ils des Entity ?

Non, il existe également des Value Objects — ils n'ont pas d'unicité, leur état définit complètement leur identité.

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

La décomposition en microservices signifie-t-elle l'application du DDD ?

Non, il est possible d'appliquer le DDD même dans une application monolithique, en établissant des frontières internes des contextes.

Un repository est-il toujours nécessaire pour chaque agrégat ?

En général oui, mais parfois un agrégat peut être entièrement stocké comme partie d'un autre agrégat s'il n'est pas la racine d'une transaction métier distincte.