ubiquitous-language

name: ubiquitous-language description: Extrait un glossaire de langage omniprésent au style DDD de la conversation actuelle, signale les ambiguïtés et propose des termes canoniques. Sauvegarde dans UBIQUITOUS_LANGUAGE.md. Utilise quand l'utilisateur veut définir des termes métier, construire un glossaire, renforcer la terminologie, créer un langage omniprésent, ou mentionne « domain model » ou « DDD ». disable-model-invocation: true

tags: [mattpocock, ubiquitous-language] -------- | ------------------------------------------------------- | --------------------- | | Order | La demande d'un client d'acheter un ou plusieurs articles | Purchase, transaction | | Invoice | Une demande de paiement envoyée à un client après livraison | Bill, payment request |

People

Relationships

• Une Invoice appartient à exactement un Customer
• Une Order produit une ou plusieurs Invoices

Example dialogue

Dev: « Quand un Customer passe une Order, créons-nous l'Invoice immédiatement ? » Domain expert: « Non — une Invoice n'est générée que lorsqu'un Fulfillment est confirmé. Une seule Order peut produire plusieurs Invoices si les articles sont expédiés dans des Shipments séparés. » Dev: « Donc si un Shipment est annulé avant expédition, aucune Invoice n'existe pour lui ? » Domain expert: « Exactement. Le cycle de vie de l'Invoice est lié au Fulfillment, pas à l'Order. »

Flagged ambiguities

• « account » a été utilisé pour signifier à la fois Customer et User — ce sont des concepts distincts : un Customer passe des commandes, tandis qu'un User est une identité d'authentification qui peut ou non représenter un Customer.

Rules

• Sois opinionated. Quand plusieurs mots existent pour le même concept, choisissez le meilleur et liste les autres comme alias à éviter.
• Signale les conflits explicitement. Si un terme est utilisé de manière ambiguë dans la conversation, appelle-le dans la section « Flagged ambiguities » avec une recommandation claire.
• Inclus seulement les termes pertinents pour les experts métier. Omet les noms de modules ou de classes sauf s'ils ont un sens dans le langage métier.
• Garder les définitions concises. Une phrase maximum. Définis ce qu'il EST, pas ce qu'il fait.
• Montre les relations. Utilise les noms de termes en gras et exprime la cardinalité quand elle est évidente.
• Inclus seulement les termes métier. Ignore les concepts génériques de programmation (array, function, endpoint) sauf s'ils ont une signification spécifique au domaine.
• Groupe les termes en plusieurs tables quand des clusters naturels émergent (p. ex. par sous-domaine, cycle de vie, ou acteur). Chaque groupe a son propre titre et tableau. Si tous les termes appartiennent à un domaine cohésif, un tableau suffit — ne force pas les regroupements.
• Écris un exemple de dialogue. Une courte conversation (3-5 échanges) entre un dev et un expert métier qui démontre comment les termes interagissent naturellement. Le dialogue doit clarifier les limites entre les concepts liés et montrer les termes utilisés précisément.

<example>

Example dialogue

Dev: « Comment tester le sync service sans Docker ? »

Domain expert: « Fournis la filesystem layer à la place de la Docker layer. Elle implémente la même interface Sandbox service mais utilise un répertoire local comme sandbox. »

Dev: « Donc sync-in crée toujours un bundle et le déplie ? »

Domain expert: « Exactement. Le sync service ne sait pas à quelle couche il parle. Il appelle exec et copyIn — la filesystem layer exécute juste ceux-ci comme des commandes shell locales. »

</example>

Re-running

Quand invoqué à nouveau dans la même conversation :

1. Lis l'UBIQUITOUS_LANGUAGE.md existant
2. Incorpore tout nouveau terme de la discussion ultérieure
3. Mets à jour les définitions si la compréhension a évolué
4. Resignale les nouvelles ambiguïtés
5. Réécris le dialogue d'exemple pour incorporer les nouveaux termes