01 - Le domaine métier : la fondation de tout
Ce que tu vas apprendre
- Ce qu'est un domaine métier (et ce que ce n'est pas)
- Les composants d'un domaine bien défini
- Comment distinguer un bon nom de domaine d'un mauvais
- Pourquoi le domaine est le contrat le plus important de ton système
Prerequisites
Qu'est-ce qu'un domaine métier ?
Un domaine métier (ou simplement "domaine") est un perimetre fonctionnel coherent de ton logiciel. C'est la réponse a : "de quoi parle cette partie du système ?".
Attention : on ne parle pas de "domaine" au sens DNS (comme google.com). On parle du concept issu du DDD (Domain-Driven Design), une approche de conception logicielle inventee par Eric Evans. L'idee centrale du DDD : le code doit refleter la réalité métier, pas l'inverse.
Un domaine, c'est :
- Un espace problème borne : il a des limites claires
- Avec son propre vocabulaire : les mots ont un sens precis
- Ses propres invariants : des regles qui doivent toujours etre vraies
- Ses propres regles de cycle de vie : comment les choses evoluent
Exemples concrets :
- Cycle de vie Place : tout ce qui concerne un lieu touristique, de sa création a sa publication
- Reglement des paiements : tout ce qui concerne le passage d'une commande au paiement effectif
- Publication de contenu : tout ce qui concerne la mise en ligne d'un article ou d'un media
Ce qu'un domaine n'est PAS
C'est aussi important de savoir ce qu'un domaine n'est pas :
- Pas un projet : un projet a une date de début et de fin. Un domaine persiste.
- Pas une feature : une feature est un point d'entree utilisateur. Un domaine est le socle sous les features.
- Pas un schema de base de donnees : la base de donnees est un détail d'implementation. Le domaine existe meme sans base de donnees.
- Pas une architecture technique : "le backend" n'est pas un domaine. "le microservice users" non plus.
Les composants d'un domaine
Un domaine bien défini contient toujours ces éléments :
1. Un nom
Court, explicite, non technique. Il doit parler a quelqu'un qui ne code pas.
| Bon nom | Mauvais nom |
|---|---|
| Cycle de vie Place | Backend |
| Reglement des paiements | API v2 |
| Publication de contenu | Logique du dashboard |
2. Un objectif
Un paragraphe maximum qui répond a : pourquoi ce domaine existe ? Quel résultat il garantit ?
Test : si deux domaines ont le meme objectif, l'un des deux est de trop.
3. Des entités
Les "noms" du domaine. Les objets qui ont une identité. On les verra en détail dans l'article suivant.
Exemple : Place, ImageAsset, Publication.
Ce qui n'est PAS une entité : un DTO (Data Transfer Object -- un objet qui sert juste a transporter des donnees), une table SQL, un payload d'API.
4. Un cycle de vie
Comment l'entité principale evolue dans le temps. C'est l'ossature du domaine. On y consacre un article entier (article 03).
5. Des invariants
Ce qui doit toujours etre vrai dans un état donne. Exemple : "Une Place en état PUBLISHED doit avoir au moins 3 URL d'image valide."
6. Des frontieres
Ce que le domaine ne gere pas. C'est écrit de manière negative pour empecher le debordement de scope.
Exemple : "Ce domaine ne gere pas l'authentification utilisateur."
7. Une terminologie
Un glossaire. Un mot = un sens. Pas de synonymes. Si deux mots veulent dire la meme chose, tu en choisis un et tu supprimes l'autre.
Le domaine est le contrat le plus eleve
Voici la regle fondamentale : si le domaine est incorrect, tout ce qui est construit dessus l'est aussi.
Le code change. Les features changent. L'infrastructure change. Le domaine est ce qui doit survivre a tout cela.
Un domaine est valide quand :
- On peut dessiner son cycle de vie sans écrire de code
- Chaque feature se mappe a une ou plusieurs transitions du cycle de vie
- Chaque bug peut etre decrit comme un invariant casse
- Supprimer une feature ne casse pas la définition du domaine
C'est un principe qu'on applique au quotidien sur paltemps.fr, ou chaque fonctionnalité est pensee autour du domaine avant d'etre codee.
Exercice : identifier le domaine d'une todo app
Prends une application de todo classique. Essaie de répondre :
- Quel est le nom du domaine ?
- Quelle est l'entité principale ?
- Quels sont les états possibles d'une todo ? (indice : il y en a au moins 3)
- Quel invariant pourrait exister pour l'état "complète" ?
- Quelle frontiere tu definirais ?
Résumé
- Un domaine métier est un perimetre fonctionnel avec son vocabulaire, ses regles et ses frontieres
- Ce n'est ni un projet, ni une feature, ni un schema technique
- Ses composants : nom, objectif, entités, cycle de vie, invariants, frontieres, terminologie
- C'est le contrat le plus eleve : s'il est faux, tout ce qui en decoule est faux
Article précédent : 00 - Introduction Article suivant : 02 - Entités, Value Objects et identité