Modèle d’exécution : rôles

Une enveloppe de requête a été définie. Une méthode a été définie. Ce qui les relie ne l’a pas été.

L’article 9 a fermé la surface contractuelle. Chaque méthode possède maintenant une enveloppe de requête déclarée, une enveloppe de réponse déclarée, et un modèle à trois issues pour ce qu’un appel peut produire. La forme de la communication est entièrement spécifiée. La méthode est entièrement spécifiée.

Ce qui n’a pas été spécifié, c’est ce qui se passe entre les deux.

L’enveloppe de requête porte une adresse : module.method. Quelque chose doit lire cette adresse, localiser la cible, et transférer le contrôle à la frontière d’exécution de la méthode. Quelque chose a dû assembler l’enveloppe en premier lieu. Quelque chose a dû décider que l’exécution devait commencer. Ce ne sont pas des détails d’implémentation. Ce sont des positions dans le modèle d’exécution — des positions qui peuvent être occupées par le mauvais type de script, produisant les mêmes défaillances que les articles précédents ont cherché à prévenir.

Cet article définit ces positions. Chaque script du système occupe un rôle. Chaque rôle possède un ensemble de permissions contraint. Un script qui agit hors de son rôle est invalide, quel qu’en soit le résultat.

Nouveaux concepts introduits

• Rôle de script
• Script d’interface
• Appelant
• Script d’entrée de méthode
• Script d’infrastructure
• Script de frontière de session

Le problème de l’exécution non classifiée

L’article 8 a établi que le comportement appartient aux méthodes, pas aux scripts. Un script est un mécanisme d’implémentation. Une méthode est une unité architecturale. Les deux occupent des positions différentes dans le modèle.

Mais une solution FileMaker contient de nombreux scripts qui n’implémentent pas de méthodes. Des scripts qui construisent des enveloppes de requête. Des scripts qui naviguent entre modèles. Des scripts qui initialisent l’état de session. Des scripts qui répondent à des clics de bouton. Des scripts qui orchestrent des séquences d’appels de méthodes au nom d’une action utilisateur.

Aucun de ceux-là n’est une méthode. Aucun ne disparaît du système parce que les méthodes existent maintenant. L’architecture doit rendre compte de tous — non pas pour les éliminer, mais pour les contraindre. Le même raisonnement qui a conduit à définir ce qu’est une méthode conduit à définir ce qu’est tout le reste.

Dans un système sans classification, la frontière établie dans l’article 8 est perméable dès le départ. Un script qui prétend être un appelant mais contient une règle métier a violé la séparation entre orchestration et logique. Un script attaché à un objet de modèle qui valide un enregistrement a contourné entièrement la couche méthode. Un script qui initialise une session mais effectue aussi une recherche a confondu deux responsabilités distinctes. Aucune de ces violations n’est détectable par le nom ou l’emplacement seuls — parce qu’aucun modèle n’existe pour contraindre ce que chaque script est autorisé à faire.

Ce type de défaillance est familier. C’est la même défaillance décrite dans l’article 3 : un comportement sans propriétaire déclaré, réparti invisiblement dans les artefacts d’exécution, visible seulement en lisant chaque script.

La solution est la même que pour les méthodes : définir les unités, contraindre les unités, rendre les violations visibles depuis la structure seule.

Le rôle est une contrainte, pas une étiquette

Un rôle de script n’est pas une convention de nommage. Ce n’est pas une catégorie de dossier. C’est une contrainte sur le comportement autorisé.

Un rôle définit trois choses pour chaque script qui le détient :

• quelles opérations le script est autorisé à effectuer
• ce que le script a l’interdiction de faire
• où dans le modèle d’exécution le script est autorisé à apparaître

Si le rôle d’un script ne peut pas être inféré de son nom et de son emplacement dans l’espace de travail des scripts sans lire son corps, le nommage ou l’organisation est invalide. La visibilité du rôle n’est pas une préférence. C’est le mécanisme par lequel les violations deviennent détectables.

Le critère d’audit en découle directement : si un réviseur doit ouvrir un script pour en déterminer le rôle, le nommage ou l’organisation de l’espace de travail a échoué. Ce critère est l’équivalent pour les rôles du test de TO de l’article 7. Tous deux vérifient la même propriété — si le modèle d’application peut être lu depuis la structure seule, sans exécution. Un système où les violations de rôle exigent de lire chaque script pour être détectées est un système où ces violations sont indétectables en pratique. L’organisation de l’espace de travail n’est pas administrative. C’est la surface d’application de la typologie.

Cinq rôles d’exécution existent dans ce modèle. Les rôles définis ci-dessous sont des concepts architecturaux. Leurs descriptions expliquent les responsabilités que chaque rôle détient dans le modèle d’exécution. Les références aux scripts reflètent la plateforme de démonstration utilisée tout au long de cette série — une réalisation de ces rôles, et non une exigence que toute implémentation suive le même mécanisme. Chaque rôle est défini par ce qu’il est autorisé à faire — pas par ce qu’il fait typiquement, et pas par son nom.

Scripts d’interface

Un script d’interface est attaché au comportement de modèle. Il gère l’état de présentation : navigation, contexte de modèle, actions d’affichage seul, interactions qui existent entièrement dans la couche d’interface et ne produisent aucun effet métier.

Les scripts d’interface sont exempts de la chaîne de passerelle pour les déclencheurs directs. Un bouton peut invoquer un script d’interface directement. Un déclencheur de script de modèle peut invoquer un script d’interface directement. Cette exemption est bornée : elle s’applique au déclencheur, pas à ce que le script d’interface peut faire.

Ce qu’un script d’interface est autorisé à faire :

• naviguer entre les modèles
• définir l’état de la couche présentation
• déclencher l’exécution en invoquant un appelant — qui entre alors normalement dans la chaîne de passerelle
• afficher les résultats retournés par un appelant

Ce qu’un script d’interface a l’interdiction de faire :

• implémenter des règles métier
• modifier des données directement
• appeler un routeur directement
• appeler un script d’entrée de méthode directement
• contourner la passerelle pour invoquer de la logique

L’exemption du script d’interface existe parce que le modèle d’interaction de FileMaker ne peut pas éviter les chemins de déclenchement directs depuis les objets de modèle. C’est une contrainte de plateforme FileMaker. L’exemption reconnaît la contrainte. Elle ne dissout pas la frontière. Toute exécution qui produit un effet métier doit réintégrer le modèle par un appelant.

Un script d’interface qui valide un enregistrement n’a pas effectué un écart mineur. Il a contourné le modèle d’exécution défini par cette architecture. La couche méthode ne voit pas cette mutation. Le modèle contractuel n’en est pas propriétaire. La capacité du système à raisonner sur son propre comportement a été compromise par un seul script dans un seul modèle.

Appelants

Dans le modèle, un appelant est le script qui initie l’exécution d’une méthode. Il assemble l’enveloppe de requête et achemine l’appel.

Un appelant est orienté interface ou interne. Un appelant orienté interface répond à une action utilisateur — un clic de bouton, une soumission de formulaire, un déclencheur — et traduit cette action en appel de méthode structuré. Un appelant interne est invoqué par un autre script de la couche d’orchestration et effectue la même traduction sans attachement direct à l’interface.

Ce qu’un appelant est autorisé à faire :

• assembler l’enveloppe de requête (module, method, obj, meta, callbackData)
• acheminer l’appel par la passerelle
• recevoir l’enveloppe de réponse
• bifurquer selon l’issue — succès, sortie anticipée, ou échec
• effectuer le traitement post-exécution basé sur la réponse

Ce qu’un appelant a l’interdiction de faire :

• contenir des règles métier
• modifier des données directement
• appeler un routeur directement
• appeler un script d’entrée de méthode directement
• contourner la passerelle

L’appelant est une unité d’orchestration. Il décide quoi appeler et quand. Il ne décide pas comment la méthode s’exécute, et il ne participe pas à sa logique. Un appelant qui contient une règle métier n’est pas un appelant. C’est un fragment de logique à la mauvaise position.

La passerelle est la frontière entre l’appelant et l’infrastructure d’exécution. L’appelant atteint cette frontière et s’arrête. Ce qui se passe au-delà n’est pas de son ressort.

Scripts d’entrée de méthode

Un script d’entrée de méthode implémente une méthode. C’est le script vers lequel l’exécution est transférée par le routeur quand l’adresse module.method a été résolue.

La raison pour laquelle une méthode exige un rôle d’exécution dédié n’est pas organisationnelle. Elle est structurelle. Chaque méthode doit exposer une frontière d’exécution stable — un point d’entrée unique et non ambigu par lequel la chaîne d’acheminement transfère le contrôle, et auquel le contrat de méthode se lie. Rien à l’extérieur de la méthode ne peut atteindre sa logique autrement que par cette frontière.

La plateforme de démonstration réalise cette frontière par un script d’entrée de méthode désigné, identifié par identifiant de script. Dans cette architecture, l’autorité de routage est liée à l’identifiant de script. Le nom est opérationnel. Le contrat — entrée déclarée, sortie déclarée, échec déclaré — est ce à quoi le script d’entrée de méthode est lié.

Ce qu’un script d’entrée de méthode est autorisé à faire :

• recevoir l’enveloppe de requête comme entrée déclarée
• exécuter la logique, la validation ou la mutation qui constitue la méthode
• retourner une enveloppe de réponse générée par les assistants contractuels

Ce qu’un script d’entrée de méthode a l’interdiction de faire :

• dépendre d’un contexte ambiant : modèle actif, sélection active, état de fenêtre, variables globales
• lire une entrée non déclarée depuis l’environnement
• interagir avec l’interface utilisateur ou participer au comportement de présentation
• être appelé directement par un appelant ou un script d’interface

Le script d’entrée de méthode reçoit un contrat, pas un contexte d’exécution. Dans ce modèle, il ne doit pas dépendre de qui l’a appelé, du modèle actif au moment de l’appel, ni de l’état de la fenêtre à l’écran. Il reçoit un contrat. Il s’exécute selon ce contrat. Il retourne un résultat.

C’est la frontière de pureté de l’article 8, rendue opérationnelle. Le script d’entrée de méthode est là où cette frontière est appliquée.

Certains scripts d’entrée de méthode implémentent directement le comportement. D’autres le délèguent. Le patron de méthode d’interface est l’exemple principal de délégation : un script d’entrée de méthode dont l’implémentation est un script adaptateur plutôt qu’un exécuteur direct. Il détient un contrat valide, reçoit l’enveloppe de requête par le chemin de routage standard, extrait les données de l’enveloppe, délègue à un script d’interface qui effectue le comportement réel, et retourne une enveloppe de réponse normalisée.

Le but est de rendre le comportement d’interface routable. Certains comportements d’interface doivent pouvoir être invoqués depuis l’extérieur du fichier qui les définit. Sans script adaptateur routable, cette invocation exige une référence directe de script — un couplage inter-fichiers qui crée un second chemin d’exécution parallèle à l’acheminement des méthodes. Le patron de méthode d’interface comble cet écart en intégrant le comportement d’interface dans le même modèle de routage utilisé partout ailleurs.

Un script implémentant le patron de méthode d’interface reste un script d’entrée de méthode. Le routeur l’invoque de façon identique. Il occupe la même position d’exécution. Ce qui diffère, c’est l’implémentation : au lieu d’effectuer directement le comportement, il délègue. La chaîne d’acheminement ne change pas. Le modèle contractuel ne change pas. Le rôle ne change pas.

Scripts d’infrastructure

Un script d’infrastructure occupe une position dans le modèle d’exécution mais n’implémente pas de comportement métier. Il soutient la mécanique de l’exécution — routage, acheminement, application des politiques — sans être un acteur dans la logique métier que ces mécaniques servent. Son rôle est de gouverner comment le comportement est atteint, et non de l’exécuter.

La plateforme de démonstration réalise ce rôle par la passerelle et le routeur. La passerelle reçoit l’enveloppe de requête de l’appelant et constitue le point d’entrée obligatoire dans la chaîne d’acheminement. Le routeur résout l’adresse module.method et transfère le contrôle au script d’entrée de méthode désigné. Tous deux sont des participants d’infrastructure : ils gouvernent l’accès à l’exécution sans participer à son contenu.

Ce qu’un script d’infrastructure est autorisé à faire :

• soutenir la mécanique d’exécution du modèle (routage, acheminement, application des politiques)
• effectuer des services de plateforme transversaux

Ce qu’un script d’infrastructure a l’interdiction de faire :

• contenir de la logique métier
• être confondu avec une méthode
• être appelé directement par des appelants comme s’il était un script d’entrée de méthode

Scripts de frontière de session

Un script de frontière de session est invoqué par des événements du cycle de vie de la plateforme — OnFirstWindowOpen, OnLastWindowClose, et les déclencheurs de session équivalents — pas par la chaîne d’acheminement. Cette distinction définit sa position d’exécution. Il ne se trouve pas à l’intérieur du modèle d’exécution. Il le délimite.

Le modèle d’exécution devient disponible après le démarrage de la session et reste disponible jusqu’à la fin de la session. Les appelants, les scripts d’entrée de méthode, les scripts d’interface et les scripts d’infrastructure s’exécutent tous dans cette fenêtre. Les scripts de frontière de session s’exécutent à ses limites : avant que la chaîne d’acheminement soit disponible, ou après qu’elle a pris fin. Gouvernance du démarrage, initialisation de session, gestion de la fin de session, application de la politique de fermeture — ce ne sont pas des préoccupations de méthode. Ce sont des préoccupations de frontière. Aucun contrat ne les gouverne. Aucun routeur ne les appelle. Ils existent parce que la session a un cycle de vie qui commence et se termine hors de portée du modèle d’exécution.

C’est ce qui distingue les scripts de frontière de session des scripts d’infrastructure. Les scripts d’infrastructure soutiennent l’exécution depuis l’intérieur du modèle actif — la passerelle, le routeur et les assistants d’acheminement dépendent tous d’un modèle d’exécution en cours de fonctionnement. Les scripts de frontière de session s’exécutent précisément quand ce modèle n’est pas encore opérationnel, ou quand il a déjà pris fin. Les deux rôles occupent des positions différentes dans la chronologie, pas seulement des domaines fonctionnels différents.

L’initialisation de session est l’une des responsabilités de ce rôle, mais le rôle est plus large que la seule initialisation. Il gouverne l’exécution aux deux extrémités du cycle de vie de la session — au démarrage et à l’arrêt — pas seulement au début.

Ce qu’un script de frontière de session est autorisé à faire :

• établir l’état de session requis par les appelants et les méthodes
• appliquer les politiques de démarrage (configuration de fenêtre, politiques de menu, règles d’accès)
• gérer la gouvernance de l’arrêt et de la fermeture
• s’exécuter aux événements d’ouverture de fichier, de début de session, de fin de session ou de fermeture de fichier

Ce qu’un script de frontière de session a l’interdiction de faire :

• implémenter des règles métier
• modifier des données métier canoniques hors d’une méthode
• être appelé dans le cadre d’une chaîne d’acheminement de méthode

Un script de frontière de session n’est pas une méthode. Acheminer l’exécution vers lui, l’appeler avec une enveloppe contractuelle, le traiter comme une cible d’exécution adressable — ce sont des applications incorrectes du modèle. Son déclencheur est la plateforme. Sa portée est la frontière de session. Dans la session active, le modèle ne l’adresse pas.

Les définitions de rôles ci-dessus convergent vers deux chemins d’exécution autorisés : l’invocation directe des scripts d’interface par des déclencheurs ou boutons de modèle, et l’invocation routée par la chaîne d’acheminement pour tout le reste. Le mécanisme qui rend ces chemins valides — et tous les autres invalides — est la passerelle. Ce mécanisme appartient à un article ultérieur. Ce qui vient ensuite établit ce que chaque participant à l’exécution doit faire après le retour d’un appel.

Organisation de l’espace de travail

La gouvernance des rôles est appliquée par la structure physique. L’espace de travail des scripts est organisé par statut architectural, pas par fonctionnalité. Chaque script du système vit dans une section de l’espace de travail qui rend son rôle ou son appartenance à un patron visible depuis l’emplacement seul. Le dossier lui-même constitue la déclaration. Le nom du script, dans ce dossier, identifie le script spécifique.

La plupart des dossiers de premier niveau de l’espace de travail correspondent directement à un rôle d’exécution. UI contient les scripts d’interface. CALLERS contient les scripts appelants. METHODS contient les scripts d’entrée de méthode. INFRASTRUCTURE contient les scripts d’infrastructure. SESSION contient les scripts de frontière de session. Le nom du dossier n’est pas le nom du rôle — le nom du rôle est celui défini dans le modèle d’exécution — mais la correspondance est univoque. Le dossier d’un script déclare son rôle.

EDITOR est l’exception. Ce n’est pas un dossier de rôle. C’est une section dédiée de l’espace de travail pour un patron qui combine légitimement l’interaction côté interface avec l’orchestration de style appelant — la chorégraphie de session d’édition qui doit rester visible comme un tout plutôt que dispersée dans CALLERS et UI. EDITOR existe parce que l’architecture exige que ce patron soit localisé. Il n’existe pas parce qu’un rôle d’exécution correspondant existe.

Le modèle organisationnel suit les définitions de rôles et d’espace de travail ci-dessus :

UI
│
├─ UI - Ouvrir fenêtre projet
└─ UI - Actualiser tableau de bord

EDITOR                        ← section d'espace de travail, pas un rôle d'exécution
│
└─ Éditeur - Projet

CALLERS
│
├─ Appelant - Ouvrir projet
├─ Appelant - Sauvegarder projet
└─ Appelant - Supprimer projet

METHODS
│
└─ project
   ├─ project.create
   ├─ project.update
   └─ project.delete

INFRASTRUCTURE
│
├─ Passerelle
├─ Routeur (local)
└─ Assistant d'acheminement

SESSION                       ← scripts de frontière de session
│
└─ Initialiser session

Les concepts architecturaux sont canoniques. Les étiquettes de dossiers ne le sont pas. Les noms présentés ci-dessus — UI, EDITOR, CALLERS, METHODS, INFRASTRUCTURE, SESSION — sont les conventions de l’auteur, pas de la doctrine. Une solution peut utiliser des étiquettes d’espace de travail différentes, pourvu que la correspondance entre dossier et rôle d’exécution reste explicite et non ambiguë depuis la structure seule. Ce qui n’est pas flexible, c’est la correspondance elle-même : chaque rôle d’exécution doit avoir une section dédiée de l’espace de travail, EDITOR doit exister comme section pour la chorégraphie de session d’édition, et aucun rôle ne peut être absorbé silencieusement dans un autre dossier.

Ce n’est pas une suggestion. C’est la structure qu’exige le modèle d’application. Un script dont le rôle ne peut pas être déterminé depuis son dossier est dans le mauvais dossier. EDITOR est la seule section de premier niveau qui ne correspond pas à un seul rôle d’exécution — et cette exception a une justification architecturale explicite.

L’organisation par fonctionnalité — regrouper les scripts par le domaine qu’ils servent plutôt que par le rôle qu’ils détiennent — inverse cela. Un dossier Projet contenant un appelant, un script d’entrée de méthode et un script d’interface a mélangé trois rôles dans un même dossier. Les violations deviennent invisibles. L’espace de travail ne peut plus être lu comme une surface d’application.

L’organisation par rôle fait de l’espace de travail un outil d’audit. D’un coup d’œil, le rôle de chaque script est déclaré par son emplacement. Les violations apparaissent comme des erreurs de classement, pas comme de la logique cachée.

La section EDITOR de l’espace de travail

La chorégraphie de session d’édition ne s’inscrit pas proprement dans un seul rôle d’exécution. Un script d’éditeur initialise l’état — c’est du comportement côté interface. Il répond aux déclencheurs de sauvegarde et d’annulation — c’est aussi du comportement côté interface. Quand l’utilisateur confirme une sauvegarde, il assemble l’enveloppe de requête et achemine un appel de méthode — c’est du comportement d’appelant. Il efface l’état à la fin — interface à nouveau.

Les deux rôles sont légitimement présents. L’architecture ne veut pas l’interdire. Elle veut le localiser.

Sans section dédiée de l’espace de travail, les scripts de session d’édition seraient distribués dans CALLERS et UI — le cycle de vie réparti sur deux dossiers, la chorégraphie invisible comme unité. Le dossier EDITOR existe pour prévenir cela. C’est une section dédiée de l’espace de travail pour un patron qui combine légitimement l’interaction côté interface avec l’orchestration de style appelant, et qui doit rester visible comme un tout.

Il s’agit d’un statut architectural différent de celui d’un rôle d’exécution. EDITOR ne décrit pas une position unique dans le modèle d’exécution. Aucune nouvelle permission n’est introduite. Les opérations effectuées par les scripts dans EDITOR sont déjà permises par les rôles de script d’interface et d’appelant. Ce qu’EDITOR fournit, c’est une frontière : la contrainte que ce patron soit localisé ici, et non dispersé.

Le patron de session d’édition lui-même — édition sur surface intermédiaire, orchestration de sauvegarde, cycle de vie de session — appartient à l’article 15. Cet article établit la section de l’espace de travail que ce patron exige.

L’arborescence de l’espace de travail reflète cela. EDITOR apparaît aux côtés de CALLERS et UI comme dossier homologue, mais c’est une frontière d’espace de travail homologue — pas un rôle d’exécution homologue.

L’écart se referme

L’article 9 a laissé une question délibérément ouverte :

Appelant
  ↓
Enveloppe de requête
  ↓
?
  ↓
Méthode

Le point d’interrogation était structurel, pas rhétorique. L’écart ne pouvait pas se refermer avant que les participants aient été définis.

Cet espace est occupé par la passerelle et le routeur. Cet article a identifié leur catégorie de rôle — infrastructure — mais ne les a pas formalisés comme composants structurels. Leur formalisation vient dans les articles à venir consacrés au routeur et à la passerelle. Ce que cet article établit, c’est la précondition de cette formalisation : chaque script qui participe au chemin d’exécution a un rôle défini, et ce rôle contraint ce qu’il peut faire.

L’appelant assemble l’enveloppe. La passerelle la reçoit — en tant qu’infrastructure, dans le rôle que la typologie lui définit. Le routeur résout la cible. Le script d’entrée de méthode exécute le contrat. Aucun autre script ne peut apparaître dans cette chaîne. Un script qui apparaît dans la chaîne sans rôle défini pour cette position est une violation.

Cette séquence — appelant, passerelle, routeur, script d’entrée de méthode — décrit la réalisation du modèle d’exécution par la plateforme de démonstration. Les rôles que la typologie définit sont ce qui rend cette chaîne valide.

L’écart ne se referme pas en le remplissant de scripts non classifiés. Il se referme en contraignant chaque script qui pourrait y entrer.

Regroupements de scripts — une concession

Une méthode est parfois trop complexe pour être implémentée dans un seul script atomique. Quand la logique devient assez complexe ou que les chemins d’exécution se ramifient assez loin, un seul script devient difficile à appréhender, à maintenir ou à tester. Dans ces cas, la méthode est implémentée comme un regroupement de scripts coopérants entre eux, qui constituent ensemble une seule unité de comportement. La concession est explicite, localisée et non propagatrice.

La concession est nommée et bornée :

• le regroupement est toujours une seule méthode
• la frontière du regroupement est interne à l’implémentation
• l’identité logique de la méthode ne change pas
• le contrat ne change pas
• le regroupement ne crée pas d’unités architecturales supplémentaires

De l’extérieur de la méthode, rien ne change. L’appelant adresse module.method. Le routeur résout un seul script d’entrée. Le script d’entrée peut déléguer en interne aux scripts du regroupement. Cette délégation est un détail d’implémentation. Le modèle contractuel ne la voit pas.

Un membre du regroupement autre que le script d’entrée qui devient accessible hors de la frontière de la méthode — qui peut être appelé par un appelant, adressé par un routeur, ou déclenché par un élément d’interface — n’est pas une concession. C’est une violation structurelle.

Les scripts membres du regroupement sont des fragments d’implémentation internes à la méthode, pas des unités architecturales indépendantes. Ils ne sont pas soumis aux mêmes contraintes de frontière que le script d’entrée de méthode, parce qu’ils n’occupent pas la frontière contractuelle publique de la méthode. Le script d’entrée de méthode possède cette frontière : il reçoit l’enveloppe de requête, satisfait le contrat, et ne peut pas dépendre d’un état externe non déclaré. Les membres du regroupement évoluent à l’intérieur de cette frontière et peuvent partager l’état d’exécution contrôlé établi par le script d’entrée de méthode — y compris des mécanismes d’implémentation comme un dictionnaire de variables interne à la méthode — pourvu que l’état soit établi par la méthode elle-même, appartienne à une seule exécution de méthode, ne soit pas accessible hors du regroupement, et soit effacé à la fin de l’exécution. La concession ne relâche pas le contrat de méthode. Elle ne permet pas la dépendance envers un état ambiant non contrôlé. La distinction est entre l’état que la méthode possède et contrôle en interne, et l’état dont l’origine, la propriété ou le cycle de vie est externe à la méthode.

Les violations de rôle sont des défaillances structurelles

Un script effectuant une action hors de son rôle est invalide, quel qu’en soit le résultat.

Ce n’est pas une préférence de style. C’est la même contrainte qui gouverne les surfaces contrôlées, le graphe des OT et la frontière de pureté de méthode — appliquée maintenant au modèle d’exécution lui-même. Un appelant qui contient une règle métier ne produit pas toujours un résultat incorrect. Il peut produire un résultat correct la plupart du temps. La violation n’est pas dans le résultat. Elle est dans la structure. L’architecture ne peut pas raisonner sur un comportement qu’elle ne peut pas localiser. Une règle métier dans un appelant est un comportement sans propriétaire déclaré, exprimé dans une couche qui n’est pas autorisée à le posséder.

Le mécanisme d’application est l’espace de travail des scripts. Les scripts sont organisés par rôle. Les dossiers sont nommés par rôle. Le rôle d’un script doit être inférable de son nom et de son emplacement sans lire son corps. Si ce n’est pas le cas, l’organisation a échoué — et avec elle, l’applicabilité de la typologie.

C’est le principe « lisibilité = applicabilité », appliqué pour la troisième fois dans cette série : d’abord au graphe des OT dans l’article 7, ensuite à la frontière de pureté de méthode dans l’article 8, maintenant au modèle d’exécution dans son ensemble. Ce n’est pas une coïncidence que le même principe réapparaisse. C’est une propriété de l’architecture : les contraintes qui ne peuvent pas être lues ne peuvent pas être appliquées, et les contraintes qui ne peuvent pas être appliquées n’existent pas.

La classification des rôles n’est pas la seule contrainte architecturale qui gouverne un script. La doctrine de responsabilité des fichiers établie dans l’article 6 impose une contrainte de placement indépendante : quel fichier est autorisé à héberger un rôle donné. Un script qui satisfait toutes les exigences de rôle introduites dans cet article — permissions correctes, placement correct dans l’espace de travail, position correcte dans la chaîne d’exécution — reste architecturalement invalide s’il apparaît dans un fichier qui n’est pas autorisé à héberger ce rôle. Un script d’interface dans le fichier Logic est correctement classifié. C’est quand même une violation. Les deux contraintes doivent être satisfaites indépendamment. Ni l’une ne se substitue à l’autre.

Ce que le modèle d’exécution rend possible

Le modèle d’exécution possède maintenant une typologie complète. Chaque script du système appartient à l’un des cinq rôles. Chaque rôle porte un ensemble de permissions défini. Chaque violation de permission est une violation structurelle, visible depuis l’organisation seule. L’espace de travail identifie aussi EDITOR comme section dédiée à la chorégraphie de session d’édition — un patron qui combine le comportement d’interface et appelant d’une façon que l’architecture veut localisée plutôt que distribuée.

L’écart entre l’enveloppe et la méthode a été partiellement refermé. Les participants ont été définis. Leurs positions ont été définies. Leurs opérations autorisées ont été définies.

Ce qui reste, c’est de formaliser le routeur et la passerelle comme composants structurels — pas comme rôles de script, mais comme éléments architecturaux obligatoires avec leurs propres invariants et leurs propres conditions d’application. Avant que cette formalisation puisse avoir lieu, le prochain article établit ce que chaque participant à l’exécution doit faire après le retour d’un appel — le protocole universel que tous les participants partagent, quel que soit leur rôle.

La typologie établie ici est la précondition. Avant que la passerelle puisse être formalisée, les scripts qui l’alimentent doivent être contraints. Avant que le routeur puisse être formalisé, les scripts vers lesquels il achemine doivent être typés. La classification vient en premier. La formalisation suit.

Un système ne peut appliquer que ce qu’il peut nommer. Le modèle d’exécution possède maintenant des noms pour tout ce qui s’exécute en son sein.

Cet article reflète ma propre expérience et ma perspective. De nombreuses idées ici ont été façonnées par des contributions venues de forums, de communautés, de blogues et de livres blancs. Des outils d'IA ont été utilisés comme assistant à la rédaction pour structurer et affiner le contenu.