Imagine que tu construis une pièce de théâtre. Tu ne commences pas par choisir les projecteurs ou la peinture du décor. Tu commences par l’histoire, le scénario et les personnages. C’est exactement ça, le Domain-Driven Design.
Le domaine = l’histoire
L’histoire que tu veux raconter, c’est ton problème métier : vendre des produits, gérer des comptes, faire des réservations…
Le domaine est le cœur de l’application : ce que fait ton système dans la vraie vie.
Les acteurs = les entités
Chaque personnage important de la pièce a un nom, un rôle, une identité.
En DDD, ce sont les entités : Client, Produit, Commande. Ils vivent longtemps et évoluent avec une identité propre.
Les rôles = les services
Certains rôles ne sont pas des personnages, mais des fonctions clés : éclairagiste, régisseur…
Ce sont les services du domaine : ils réalisent des actions (payer une commande, générer un reçu), mais n’ont pas d’identité.
Le script = les cas d’usage (Application Layer)
Le scénario, c’est la suite des scènes. Qui parle ? Que se passe-t-il ?
Ce sont les cas d’usage : commander un produit, s’inscrire, ajouter un article au panier.
La scène = l’interface utilisateur
L’interface, c’est ce que voit le spectateur. Mais tout ce qui compte, c’est que l’histoire reste cohérente.
L’interface est découplée du domaine, elle reflète ce qui se passe, sans piloter le cœur.
Le décor = l’infrastructure
Éclairage, rideaux, murs : nécessaires, mais secondaires.
Base de données, APIs externes, envoi d’emails — ce sont les détails techniques, pas le cœur du système.
Les répétitions = le langage commun
Pour que tout le monde joue la même pièce, il faut un vocabulaire partagé entre les acteurs, l’auteur et le metteur en scène.
C’est le Ubiquitous Language : développeurs et experts métier utilisent le même langage, sans ambiguïté.
Résumé
Domain-Driven Design, c’est écrire la bonne pièce, avec les bons rôles, pour le bon public, en séparant bien l’histoire du décor.
- Concentre-toi sur le métier (le domaine)
- Organise ton code comme tu organiserais une troupe de théâtre
- Laisse les détails techniques en coulisse (infrastructure)
- Parle le même langage que ton client (ubiquitous language)
