Domain-Driven Design – Thomas Quenault

Qu'est-ce que le DDD ?

Le Domain-Driven Design (DDD) est une approche de conception logicielle introduite par Eric Evans en 2003. Son principe fondamental : le code doit refléter fidèlement le domaine métier de l'application, et non l'inverse.

Le DDD encourage une collaboration permanente entre développeurs et experts métier pour construire un modèle partagé du domaine, exprimé dans un langage commun.

Idée clé : Si le code et le métier parlent le même langage, les évolutions sont plus naturelles, les bugs moins fréquents et la compréhension mutuelle facilitée.

Concepts fondamentaux

Ubiquitous Language – Langage ubiquitaire

Un vocabulaire commun et précis, partagé entre développeurs et experts métier, utilisé aussi bien dans les conversations que dans le code. Pas de traduction entre le "langage business" et le "langage technique".

Bounded Context – Contexte délimité

Le domaine est découpé en contextes délimités, chacun ayant son propre modèle cohérent. Un même terme peut avoir des significations différentes selon le contexte (ex: "Client" n'est pas identique dans le service de facturation et dans le service de livraison).

Exemple de Bounded Contexts

Facturation

Client → Payeur

⟷

Livraison

Client → Destinataire

⟷

Support

Client → Demandeur

Entités (Entities)

Objets définis par une identité unique qui persiste dans le temps, indépendamment de leurs attributs. Exemple : un utilisateur identifié par son ID même si son nom change.

Objets-valeurs (Value Objects)

Objets définis uniquement par leurs attributs, sans identité propre. Deux objets-valeurs avec les mêmes attributs sont équivalents. Exemple : une adresse postale, un montant monétaire.

Agrégats (Aggregates)

Groupe d'entités et d'objets-valeurs traité comme une unité cohérente. Chaque agrégat a une racine (Aggregate Root) qui contrôle l'accès aux objets internes.

// Aggregate Root : Commande
public class Commande {
    private final CommandeId id;
    private final List<LigneCommande> lignes; // entités internes
    private Montant total;                    // value object

    public void ajouterLigne(Produit produit, int quantite) {
        // La logique métier reste dans l'agrégat
        lignes.add(new LigneCommande(produit, quantite));
        recalculerTotal();
    }
}

Repositories

Abstraction de la persistance. Le domaine ne connaît pas la base de données — il interagit uniquement avec une interface, dont l'implémentation est fournie par l'infrastructure.

Domain Events

Événements représentant quelque chose qui s'est passé dans le domaine. Permettent le découplage entre contextes. Exemple : CommandeValidée, PaiementEffectué.

Les couches du DDD

Organisation en couches

Couche Présentation (UI, API REST)

↕

Couche Application (Use Cases, Services)

↕

⭐ Couche Domaine (Entités, Agrégats, Events)

↕

Couche Infrastructure (BDD, API externes, Messaging)

DDD stratégique vs tactique

DDD Stratégique

Vision macro : découper le système en Bounded Contexts, définir leurs relations (Context Map), établir le langage ubiquitaire. C'est une conversation avec le métier.

DDD Tactique

Vision micro : implémenter les patterns (entités, agrégats, value objects, repositories, domain events) dans le code. C'est du design objet guidé par le métier.

Quand utiliser le DDD ?

Domaine complexe : logique métier riche avec beaucoup de règles
Équipe pluridisciplinaire : développeurs + experts métier en collaboration
Long terme : application amenée à évoluer dans la durée
Microservices : les Bounded Contexts guident naturellement le découpage des services

À éviter pour : les CRUD simples, les petits projets, les scripts de traitement ponctuel. Le DDD a un coût d'entrée — il se justifie quand la complexité métier le mérite.

Outils & frameworks Java

Spring Boot Axon Framework jMolecules Hibernate Spring Data