Conventions de nommage¶
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). Objectif : supprimer la dérive — get/find/list interchangeables, six mots pour « réussi » (confirmed/succeeded/paid/…), entrées tantôt Payload tantôt Input tantôt Body, booléens moitié préfixés.
Source de vérité unique
Les règles complètes vivent dans une règle toujours active chargée automatiquement par les agents (Cursor + Claude Code), pas recopiées ici pour éviter toute dérive :
Principe¶
- Un nom par (couche, intention). Le verbe encode l'intention :
get*= lecture à présence attendue,find*= lecture nullable-by-design,process*= workflow async,compute*= calcul pur, etc. - Un terme par concept. Le lexique de statuts fige un mot canonique par état (
confirmed,pending,failed,refunded…) et bannit ses synonymes. - Un vocabulaire de domaine fermé.
brick,investor,project,echeancier,money-in,p2p… — pas de variantes libres, termes legacy figés (property,customer), vocabulaire métier français jamais traduit.
Ce que couvre la règle¶
Verbes par couche (repository / service / business / controller) · suffixes de type (Payload, Response, T) · préfixes booléens · nommage des collections, maps, compteurs · suffixes de champ · lexique des statuts (terme canonique + synonymes bannis + casing) · vocabulaire de domaine · nommage des modules.
Portée¶
S'applique au nouveau code (src/__new/). L'existant n'est pas renommé sans demande explicite. Quelques points restent à trancher dans une passe dédiée (forme des réponses & pagination, mécanisme d'enum, application aux tests, enforcement lint) — listés en fin de règle.