Patterns et frontieres d'extension

Statut documentaire : architecture — voir Maturité et preuves.

Une extension sure ajoute une capacite reutilisable sans deplacer le sens metier dans une implementation opaque.

Preferer capacites enregistrees, adapters explicites, actions publiees, services declaratifs et composants concrets remplacables. Nommer les points d'extension par la capacite fournie, pas par une technologie d'implementation. Les bindings generes sont des projections des capacites Runtime et ne doivent pas revenir dans l'ontologie uniquement parce qu'une operationnalisation utilise ce langage.

Erreurs a eviter :

• cacher un workflow metier dans une extension au lieu d'un processus/action declare ;
• exposer un helper d'implementation comme capacite publique ;
• coupler le modele a une UI, un transport ou un stockage lorsqu'une frontiere enregistree existe ;
• accepter un resultat genere ou externe avant le gate de parser, grammaire, autorisation ou validation Runtime correspondant.

Si le contrat de métadonnées exige un nom de classe concret, employer le nom publié dans l'ABI. Un identifiant présent dans les sources internes n'est pas nécessairement une API publique disponible : vérifier le manifeste ABI versionné.