Les Principes Fondamentaux du Domain-Driven Design (DDD)

Luc Bories

- 5 minutes de lecture - 1041 mots

Introduction

Dans un monde où les systèmes logiciels deviennent de plus en plus complexes, il est essentiel de concevoir des architectures qui reflètent fidèlement les besoins métier. C’est précisément l’objectif du Domain-Driven Design (DDD), une approche introduite par Eric Evans en 2003, qui place le domaine métier au cœur de la conception logicielle.

Mais DDD n’est pas qu’une méthode de modélisation. C’est une philosophie qui influence profondément l’architecture applicative, en guidant la structuration des composants, la définition des responsabilités, et la communication entre les parties du système.

Dans cet article, nous allons explorer les principes fondamentaux du DDD, et montrer comment ils s’intègrent dans une architecture applicative moderne, notamment en contexte microservices.

1. Le Domaine comme Source de Vérité

Le premier principe du DDD est que le domaine métier doit être la source principale de vérité dans la conception du logiciel. Cela signifie que les décisions techniques doivent découler des besoins métier, et non l’inverse.

Exemple :

Dans une application de gestion de prêts bancaires, les règles de calcul des intérêts, les conditions d’éligibilité, et les processus de validation doivent être modélisés en priorité, avant de penser à la base de données ou au framework utilisé.

Impact sur l’architecture :

  • Les couches techniques (base de données, UI, etc.) sont au service du domaine
  • Le modèle métier devient le cœur de l’application
  • On évite les architectures “data-centric” où les entités sont juste des tables

2. Le Langage Ubiquitaire

Le langage ubiquitaire est un vocabulaire commun partagé entre les développeurs et les experts métier. Il est utilisé dans :

  • Les discussions
  • Le code
  • La documentation

Exemple :

Si les experts parlent de “demande de prêt”, le code doit contenir une classe DemandeDePret, et non LoanRequestDTO.

Impact sur l’architecture :

  • Les noms des classes, méthodes et modules reflètent le langage métier
  • Le code devient plus lisible et plus maintenable
  • Les erreurs de compréhension entre métier et technique sont réduites

3. Le Bounded Context

Un bounded context est une frontière explicite autour d’un modèle métier cohérent. Il permet de gérer les variations sémantiques et d’éviter les conflits de sens.

Exemple :

Dans un système e-commerce :

  • Le mot “Client” dans le contexte de facturation représente une entité juridique
  • Dans le contexte marketing, il représente un profil comportemental

Impact sur l’architecture :

  • Chaque bounded context peut être implémenté comme un microservice
  • Les modèles ne sont pas partagés entre contextes
  • La communication se fait via des interfaces bien définies (API, événements)

4. Les Entités et les Valeurs

DDD distingue deux types d’objets métier :

  • Entités : ont une identité unique et persistent dans le temps (ex : Client, Commande)
  • Objets valeur : sont définis par leurs attributs et sont immuables (ex : Adresse, Montant)

Exemple :

Deux adresses identiques sont considérées comme le même objet valeur, mais deux clients avec le même nom sont des entités distinctes.

Impact sur l’architecture :

  • Les entités sont gérées par des repositories
  • Les objets valeur sont imbriqués dans les entités
  • Cela favorise une modélisation riche et précise

5. Les Agrégats

Un agrégat est un regroupement d’entités et de valeurs qui forment une unité de cohérence transactionnelle. Il a une racine (aggregate root) qui contrôle l’accès aux autres éléments.

Exemple :

Une Commande est un agrégat :

  • Racine : Commande
  • Entités internes : LigneCommande
  • Objets valeur : AdresseLivraison, Montant

Impact sur l’architecture :

  • Les opérations métier passent par la racine de l’agrégat
  • Les agrégats sont chargés et persistés en une seule unité
  • Cela améliore la consistance et la scalabilité

6. Les Services Métier

Quand une logique métier ne peut pas être placée dans une entité ou un objet valeur, elle est encapsulée dans un service métier.

Exemple :

Le calcul du taux d’intérêt d’un prêt peut être implémenté dans un service CalculateurTaux.

Impact sur l’architecture :

  • Les services métier sont stateless
  • Ils sont orientés domaine, pas infrastructure
  • Ils facilitent la réutilisation et la testabilité

7. Les Repositories

Les repositories sont des interfaces qui permettent de récupérer et persister les entités et agrégats. Ils masquent les détails techniques de la base de données.

Exemple :

Un CommandeRepository permet de :

  • findById(id)
  • save(commande)

Impact sur l’architecture :

  • Le domaine reste indépendant de la persistance
  • Les tests peuvent être faits avec des implémentations en mémoire
  • Cela favorise une architecture hexagonale (ou ports & adapters)

8. Les Domain Events

Les domain events représentent des faits métier significatifs qui se sont produits. Ils permettent de découpler les composants et de réagir aux changements.

Exemple :

  • CommandeValidée
  • ClientInscrit
  • ProduitMisÀJour

Impact sur l’architecture :

  • Les événements peuvent être publiés et consommés par d’autres services
  • Cela facilite une architecture réactive et asynchrone
  • Les événements peuvent être persistés pour l’audit ou le CQRS

9. L’Architecture Hexagonale

DDD s’intègre parfaitement avec l’architecture hexagonale, qui sépare :

  • Le domaine (au centre)
  • Les interfaces (UI, API, DB, etc.)
  • Les adaptateurs (implémentations techniques)

Exemple :

Le domaine ne connaît pas la base de données, mais expose un ClientRepository. L’implémentation est injectée via un adaptateur.

Impact sur l’architecture :

  • Le domaine est isolé et testable
  • Les dépendances sont inversées
  • Cela facilite le changement technologique sans impacter le métier

10. La Collaboration avec les Experts Métier

DDD repose sur une collaboration étroite entre développeurs et experts métier. Le but est de construire un modèle partagé qui reflète fidèlement la réalité métier.

Exemple :

Lors de la conception d’un système de gestion de sinistres, les développeurs doivent comprendre :

  • Les types de sinistres
  • Les processus de validation
  • Les règles d’indemnisation

Impact sur l’architecture :

  • Le modèle métier est plus riche
  • Les décisions techniques sont alignées avec les besoins réels
  • Le logiciel devient un outil stratégique pour l’entreprise

Conclusion

Le Domain-Driven Design n’est pas une simple méthode de modélisation. C’est une philosophie de conception qui transforme la manière dont les logiciels sont pensés, construits et maintenus.

En plaçant le domaine métier au centre, en définissant des bounded contexts clairs, en utilisant un langage ubiquitaire, et en structurant l’architecture autour des agrégats, services, repositories et événements, DDD permet de construire des systèmes robustes, évolutifs et alignés avec les besoins métier.

Dans un monde de plus en plus orienté microservices, DDD offre une boussole stratégique pour éviter les architectures fragmentées et incohérentes. Il ne s’agit pas seulement de découper le code, mais de modéliser la réalité métier avec rigueur et intelligence.