Nommage — une grammaire commune

La décision

Le nommage de l'API suit une sémantique déterministe : pour un couple (couche + intention + type) il existe un seul nom correct, et un seul terme par concept — zéro synonyme. La référence exhaustive (verbes par couche, suffixes de type, booléens, lexique des statuts, vocabulaire de domaine, noms de modules) : Conventions de nommage.

Pourquoi

• La lecture d'abord. Une grammaire commune et un vocabulaire stable simplifient énormément la lecture du code : si find* veut toujours dire « peut être absent » et get* « présence attendue », la signature porte le contrat et le lecteur n'a pas à ouvrir l'implémentation.
• Les synonymes sont du bruit. declined / rejected / refused pour le même concept forcent chaque lecteur à se demander si la nuance est intentionnelle. Un terme canonique par concept élimine la question — et les débats de review qui vont avec.
• Les agents écrivent comme nous. Un nommage déterministe rend le bon nom calculable : pour une intention donnée, humains et LLM produisent le même identifiant au lieu d'inventer des variantes.

Les principes structurants

• Le verbe porte le contrat : get/find (présence attendue / nullable), getAndLock (verrou), process (workflow transactionnel), compute/resolve/evaluate (pur)… Un seul verbe gagnant par intention et par couche.
• Statuts canoniques : confirmed, pending, failed, declined, canceled… Champ discriminant = status, valeurs en snake_case. Un enum externe qui dévie (ex. succeeded chez Lemonway) se traduit au bord, ne se migre pas — on ne touche pas à un enum de paiement en production.
• Vocabulaire de domaine fermé : brick, investor, property, project, ProjectOwner… Et les types forts complètent le nommage : un montant est un Cents, pas un number au nom suffixé.

Le détail des tables, du lexique et des interdits : Conventions de nommage.