Langage ubiquitaire et contextes bornés

Prérequis : cours 1.1 (cohésion).

Pourquoi

La moitié des bugs « métier » naissent d'un mot compris différemment par deux personnes (« commande » = panier ? validée ? expédiée ?). Le DDD commence par le vocabulaire, pas par le code.

Concepts

• Langage ubiquitaire : le vocabulaire partagé métier ↔ code, partout pareil (discussions, code, docs, UI). Si le métier dit « dossier », le code dit Folder, pas Case ni File.
• Contexte borné (bounded context) : le périmètre où un mot a UN sens. « Commande » en Vente ≠ « Commande » en Logistique : deux contextes, deux modèles — reliés par traduction, pas par partage.
• Carte des contextes : qui parle à qui, comment (API, événements, base partagée — à éviter). Dessinée avant, elle évite le modèle unique qui veut tout dire et ne dit rien.

Exemple : le mot piégé

« Client » : en Facturation = entité légale (SIRET), en Support = interlocuteur (email), en Marketing = segment. Un seul Client partagé = champs qui se contredisent (siret obligatoire ? pour le support, non). Trois modèles minces > un gros faux.

Cas réel

Refonte où « article » signifiait produit (catalogue), ligne de facture (compta) et post (blog) : un seul module ArticleService de 3000 lignes. Découpage en 3 contextes : chaque équipe avance sans marcher sur les autres.

Pièges

• Langage « à peu près » : chaque approximation est un bug en attente (« on s'est compris » famous last words).
• Contextes découpés par équipe plutôt que par sens : l'org chart n'est pas le métier (ou alors, assume-le — loi de Conway).
• Traduction bâclée entre contextes : anti-corruption layer (une couche qui protège ton modèle du vocabulaire externe), pas copier-coller.

À retenir

Un mot = un sens par contexte ; carte des contextes avant le code ; traduire, jamais partager.