aTeering/compétences

Modélisation de Domaine

Conserver une source de vérité unique et légère pour ce que les choses signifient dans ce projet, afin que le code, la documentation, les tickets et les conversations utilisent les mêmes mots pour les mêmes choses.

Focus : $ARGUMENTS (si vide, modélisez ce qui est discuté dans cette session).

Aucune hypothèse silencieuse. L'utilisateur possède ce que les termes signifient. Une définition, un nom canonique, un synonyme, une relation, une cardinalité ou un invariant que vous avez inféré du code, de la documentation ou d'une conversation est une hypothèse jusqu'à ce que l'utilisateur la confirme. Suivez-les comme ✅ confirmé · ❓ non confirmé · ❌ rejeté, et n'écrivez que les éléments confirmés dans le document de domaine en tant que faits.

Où vit le modèle

• Si GLOSSARY.md ou docs/domain.md existe déjà, utilisez-le (préférez le fichier existant ; ne créez jamais les deux).
• Sinon, créez docs/domain.md en utilisant la structure ci-dessous.

Processus

1. Lisez le document de domaine actuel et le code qui implémente les concepts en focus (types, schémas, modèles de base de données, contrats API). Le code est une preuve du modèle réel ; le document est le modèle souhaité — notez tout écart. Aucun des deux ne vous dit ce que l'utilisateur veut dire ; posez des questions sur tout écart au lieu de choisir un côté.
2. Extrayez les termes candidats de la conversation, du cahier des charges ou du ticket. Pour chacun, proposez s'il s'agit d'un nouveau terme, d'un terme existant ou d'un synonyme d'un terme existant, et faites confirmer par l'utilisateur. Deux mots qui se ressemblent peuvent être des concepts différents.
3. Résolvez les ambiguïtés avec l'utilisateur. Posez des questions courtes et concrètes :
   • "Est-ce qu'un Espace de travail est la même chose qu'une Organisation, ou une org peut-elle avoir plusieurs espaces de travail ?"
   • "Une Commande peut-elle exister sans Client ? Que doit toujours être vrai à propos d'une Commande ?" Convenez d'un nom canonique par concept avec l'utilisateur (vous pouvez en recommander un) ; listez les synonymes rejetés comme À éviter.
4. Définissez les frontières : identité (entité vs objet-valeur), propriété/racines d'agrégat, cardinalité, cycle de vie/états, et invariants. Notez à quel contexte délimité appartient un terme si le projet en a plusieurs. Proposez-les à partir du code si utile, mais confirmez chacun avec l'utilisateur.
5. Mettez à jour le document avec uniquement les éléments confirmés — diff minimal, ordre alphabétique dans les sections, pas d'essais. Si une définition change de sens, dites-le dans le commit/PR, et signalez le code qui utilise désormais le terme de manière incorrecte. Si l'utilisateur veut s'arrêter avec des éléments non résolus, ajoutez-les sous ## Questions Ouvertes marqués ❓, jamais dans le glossaire.
6. Rapportez ce que vous avez ajouté/modifié et tout écart code ↔ modèle trouvé (avec fichier:ligne), ainsi que les éléments ❓ encore ouverts.

Structure du document (gardez-le léger)

# Modèle de Domaine

## Glossaire
| Terme | Définition | À éviter |
|-------|------------|----------|
| Commande | Demande confirmée d'un client d'acheter un ou plusieurs Produits. | achat, panier |

## Entités & Agrégats
### Commande (racine d'agrégat)
- Identité : `CommandeId`
- Contient : LigneDeCommande (1..n)
- États : brouillon → passée → payée → expédiée | annulée
- Invariants : total ≥ 0 ; ne peut être expédiée sans être payée

## Relations
- Client 1 — n Commande

## Contextes Délimités (optionnel)
- Facturation : Facture, Paiement

Règles : une phrase par définition si possible ; définissez les termes en utilisant d'autres termes du glossaire ; aucun détail d'implémentation à moins qu'ils ne soient le domaine (par exemple un format d'ID que les clients voient).