Qu’est-ce que le Domain-Driven Design (DDD) pour le web ? Guide complet pour architectes et développeurs

Comprendre le Domain-Driven Design (DDD) dans le contexte web

Le Domain-Driven Design (DDD) est une approche de conception logicielle qui place le domaine métier au cœur du développement. Pour le web, cela signifie que la logique métier n’est pas noyée dans la couche de présentation ou d’infrastructure, mais constitue le pilier central de l’architecture. Au lieu de commencer par la base de données ou les API, on commence par modéliser les concepts métier en collaboration avec les experts du domaine.

Cette méthode, popularisée par Eric Evans dans son livre Domain-Driven Design: Tackling Complexity in the Heart of Software, répond à un problème récurrent : les projets web deviennent rapidement complexes et difficiles à maintenir lorsque la logique métier est dispersée. Le DDD propose une structure claire pour gérer cette complexité.

Pourquoi le DDD est pertinent pour les applications web modernes

Les applications web d’aujourd’hui ne se limitent plus à afficher des données. Elles intègrent des règles métier complexes, des workflows, des processus décisionnels. Le DDD permet de :

• Aligner le code sur le métier : les développeurs et les experts métier parlent le même langage (Ubiquitous Language).
• Réduire la complexité accidentelle : en délimitant des contextes (Bounded Contexts), on évite les dépendances inutiles.
• Faciliter la maintenance : le code est organisé autour du domaine, ce qui rend les évolutions plus sûres.
• Améliorer la testabilité : le domaine est isolé de l’infrastructure, facilitant les tests unitaires.

Les piliers du Domain-Driven Design pour le web

Le langage ubiquitaire (Ubiquitous Language)

C’est le vocabulaire partagé entre développeurs et experts métier. Par exemple, dans une application de e-commerce, on parlera de « commande », « panier », « client », « remise » – et ces termes se retrouveront dans le code, les tests, la documentation. Évitez les termes techniques comme « enregistrement », « entité », « DAO » dans les discussions métier.

Les contextes délimités (Bounded Contexts)

Un grand système web est divisé en plusieurs contextes, chacun ayant son propre modèle. Par exemple : le contexte de « gestion des commandes » et celui de « gestion des stocks » peuvent avoir leur propre définition d’un « produit ». Les contextes communiquent via des événements ou des API bien définies.

Les entités et les objets-valeurs

Une entité possède une identité unique (ex: un client avec un ID), tandis qu’un objet-valeur est défini par ses attributs (ex: une adresse). Dans une application web, on utilise ces concepts pour modéliser le domaine avec précision.

Les agrégats (Aggregates)

Un agrégat est un groupe d’objets liés, avec une racine (Aggregate Root) qui garantit la cohérence. Par exemple, une commande (racine) contient des lignes de commande ; toute modification passe par la commande. Cela simplifie la gestion des transactions.

Les événements du domaine (Domain Events)

Ils représentent des faits significatifs qui se sont produits dans le domaine (ex: « CommandeValidée »). Les événements permettent de découpler les contextes et d’intégrer des systèmes asynchrones, très utiles dans les architectures web modernes (microservices, CQRS).

DDD et architecture web : comment les appliquer

Architecture hexagonale (ports et adaptateurs)

Le domaine est au centre, entouré de ports (interfaces) et d’adaptateurs (implémentations concrètes pour la persistance, les API, l’interface utilisateur). Pour le web, l’adaptateur peut être un contrôleur MVC qui reçoit les requêtes HTTP et les traduit en appels au domaine.

DDD avec les microservices

Chaque microservice correspond idéalement à un Bounded Context. Le DDD aide à définir les frontières et les interactions entre services. Attention : ne pas confondre contexte délimité et service ; un contexte peut être implémenté par plusieurs services.

DDD et CQRS (Command Query Responsibility Segregation)

Séparer les commandes (écritures) des requêtes (lectures) est courant avec le DDD, surtout pour les applications web à fort volume. Les événements du domaine facilitent la synchronisation entre les modèles de lecture et d’écriture.

Exemple pratique : une application web de réservation de billets

Imaginons une plateforme de réservation de billets de spectacle. Sans DDD, on aurait probablement une classe Reservation avec des getters/setters et la logique métier dispersée dans les contrôleurs. Avec DDD :

• Bounded Contexts : « Gestion des spectacles », « Réservation », « Paiement », « Notification ».
• Langage ubiquitaire : « spectacle », « représentation », « place », « réservation », « confirmation ».
• Agrégat : Reservation est une racine d’agrégat qui contient les places réservées.
• Événement : ReservationConfirmée déclenche l’envoi d’un email et la mise à jour du stock.

Le contrôleur web se contente d’appeler un service applicatif qui orchestre le domaine. La logique métier (vérifier la disponibilité, calculer le prix, appliquer des réductions) est encapsulée dans les entités et les services du domaine.

Checklist pour démarrer un projet web avec DDD

• Identifier les experts métier et organiser des ateliers de modélisation (Event Storming, par exemple).
• Définir le langage ubiquitaire et le documenter.
• Délimiter les Bounded Contexts en fonction des sous-domaines (core, supporting, generic).
• Modéliser les agrégats, entités et objets-valeurs.
• Implémenter une architecture hexagonale avec injection de dépendances.
• Utiliser des événements du domaine pour les communications inter-contextes.
• Écrire des tests unitaires sur le domaine pur (sans infrastructure).
• Itérer : le DDD est un processus continu ; le modèle évolue avec la compréhension du métier.

Erreurs fréquentes à éviter avec le DDD sur le web

• Vouloir appliquer DDD partout : pour les sous-domaines génériques (authentification, logs), une approche plus simple (CRUD) suffit.
• Négliger le langage ubiquitaire : si les développeurs utilisent des termes techniques, le fossé avec le métier se creuse.
• Créer des agrégats trop gros : cela nuit à la performance et à la cohérence transactionnelle.
• Mélanger les responsabilités : ne pas mettre de logique métier dans les contrôleurs ou les repositories.
• Ignorer les événements : le couplage fort entre contextes réduit les bénéfices du DDD.

DDD vs autres approches : un tableau comparatif

Ressources pour approfondir le Domain-Driven Design pour le web

Pour aller plus loin, lisez le livre fondateur d’Eric Evans, puis explorez Implementing Domain-Driven Design de Vaughn Vernon. Des techniques comme l’Event Storming (Alberto Brandolini) sont très utiles en atelier. Côté pratique, des frameworks comme Symfony (PHP) ou Spring (Java) proposent des bundles pour implémenter le DDD.

FAQ sur le Domain-Driven Design pour le web

Le DDD est-il réservé aux grands projets web ?

Non, mais il est particulièrement utile quand la complexité métier est élevée. Pour un site vitrine simple, une approche CRUD est plus adaptée.

Faut-il utiliser DDD avec une base de données relationnelle ?

Oui, mais le modèle du domaine ne doit pas être dicté par la base de données. On utilise souvent un mapping objet-relationnel (ORM) comme Doctrine ou Hibernate.

DDD et microservices sont-ils la même chose ?

Non, mais ils se complètent. Le DDD aide à définir les frontières des microservices via les Bounded Contexts.

Quel est le rôle du développeur front-end dans le DDD ?

Le front-end consomme des API qui exposent le domaine. Il doit comprendre le langage ubiquitaire pour bien interpréter les données.

Comment gérer les performances avec le DDD sur le web ?

En utilisant des modèles de lecture optimisés (CQRS) et en évitant de charger des agrégats entiers inutilement.

Le DDD fonctionne-t-il avec JavaScript/Node.js ?

Oui, le DDD est indépendant du langage. Il existe des exemples en TypeScript avec des architectures hexagonales.

Prochaines étapes pour adopter le DDD dans vos projets web

Commencez par un atelier Event Storming avec les experts métier pour cartographier le domaine. Ensuite, choisissez un sous-domaine core et modélisez-le en respectant les principes du DDD. Implémentez une première itération avec une architecture hexagonale et testez-la. N’oubliez pas que le DDD est un voyage, pas une destination : le modèle s’affine avec le temps. Lancez-vous sur un petit périmètre pour expérimenter, puis étendez progressivement.

Photo by Matthias_Groeneveld on Pixabay