Construire le squelette

La structure est connue. Cet article lui donne forme — en assignant les rôles, en énonçant les règles d’interaction, et en établissant les contraintes avant que l’exécution commence.

L’article 5 a établi une chose : l’application des contraintes est impossible dans un espace d’exécution partagé. La frontière de fichier est le seul mécanisme structurel qui rend possible l’application des contraintes architecturales.

Cette démonstration a été faite.

La construction peut commencer. La frontière doit exister avant que l’exécution commence. Les rôles doivent être assignés avant qu’une méthode soit écrite. Les règles d’interaction doivent être énoncées avant qu’un fichier ne fasse référence à un autre.

Cet article donne forme à la structure. Pas comme un modèle — comme des fichiers avec des rôles déclarés et des contraintes explicites.

Nouveaux concepts introduits

• Concession de plateforme
• Règles d’interaction
• Passerelle

La frontière de fichier comme séparation d’exécution

Une frontière de fichier dans FileMaker fait une chose : elle sépare les espaces d’exécution.

Un comportement défini dans un fichier ne s’exécute pas dans un autre sans référence explicite. Cette référence n’est pas implicite. Elle est déclarée et vérifiable. Ce que la frontière ne fait pas, c’est imposer le contenu de ces références. Elle ne prévient pas un appel incorrect. Elle ne bloque pas une violation.

Ce qu’elle change, c’est le comportement par défaut.

Dans un fichier unique, tout est accessible depuis partout. Aucune décision n’est requise pour accéder à une table, appeler une méthode, ou lire une valeur. Le chemin de moindre résistance mène partout. Les violations ne sont pas détectables — elles ne requièrent aucune décision pour se produire.

Dans un système séparé, l’accès requiert un passage. Ce passage exige une référence — une décision. Cette décision est visible.

La frontière ne rend pas les violations impossibles. Elle les rend délibérées.

Ce à quoi ressemble un système correct

Les contraintes établies dans l’article 2 convergent vers une forme précise. Cette forme a trois couches. Chaque couche a une responsabilité. Chaque responsabilité existe à un seul endroit.

Un système correct est un système où aucune couche ne partage une responsabilité avec une autre.

Le stockage est séparé de la mutation. La couche qui détient les données ne décide pas ce qui y est écrit. Elle reçoit ce qu’on lui donne. Elle n’agit pas.

La mutation est séparée de l’initiation. La couche qui possède les règles métier ne sait pas comment une requête a été initiée. Elle reçoit une entrée déclarée et produit un résultat. Elle ne sait pas à quoi ressemble l’interface.

L’initiation est séparée de la décision. La couche qui collecte l’intention de l’utilisateur n’applique pas les règles métier. Elle construit une requête, appelle une méthode, et traite ce qui revient.

Trois couches. Trois fichiers. Aucune responsabilité partagée.

C’est la structure requise par les contraintes. Elle n’est pas proposée. Elle est imposée.

Pourquoi la structure doit exister avant l’exécution

Une fois que l’exécution débute, la structure est déjà fixée.

Un système n’assemble pas ses frontières une fois qu’il est en cours d’exécution. Les chemins d’exécution se forment dans l’espace qui existe au moment où ils sont créés. Si cet espace n’a pas de frontières définies, les chemins se forment arbitrairement — à travers tout ce qui est accessible.

L’exécution, ici, désigne une seule chose : tout point où le système peut changer d’état. C’est le seul point où une violation peut devenir réelle.

Un chemin arbitraire n’est pas visible comme problème tant qu’il ne devient pas porteur de comportement. Une fois qu’il porte du comportement, il ne peut pas être supprimé sans changer ce que le système fait. La violation n’est plus une erreur à ce stade. Elle est le système.

La structure définit les chemins possibles. L’exécution détermine lesquels deviennent réels.

Une fois qu’un chemin porte du comportement, introduire une frontière exige de réécrire ce qui en dépend — pas de le refactoriser. Le refactoring agit à l’intérieur d’une structure existante. Il ne change pas ce que la structure rend possible. La frontière doit déjà exister, ou son absence aura un coût plus tard.

La structure n’est pas quelque chose vers lequel un système évolue. C’est la précondition de ce que le système devient.

Ce qui se passe sans règles d’interaction

La séparation des fichiers est nécessaire. Elle n’est pas suffisante.

Un système de trois fichiers sans règles d’interaction n’est pas une architecture en couches. C’est la même architecture qu’un fichier unique — distribuée sur trois espaces d’exécution au lieu d’un.

Le nombre de fichiers n’est pas le problème. Le problème est comment les fichiers sont autorisés à interagir entre eux. Sans règles d’interaction explicites, le comportement par défaut s’applique : tout peut appeler tout. Un fichier d’interface appelle la couche données directement. La logique se fragmente dans le fichier qui en a eu besoin en premier. Les dépendances s’accumulent dans toutes les directions. Les violations sont identiques à celles documentées dans l’article 3. La seule différence est qu’elles requièrent maintenant des références explicites — ce qui les rend vérifiables, mais pas absentes.

La séparation des fichiers retire le chemin par défaut pour l’accès inter-frontières. Les règles d’interaction déterminent ce qui le remplace.

Sans règles, rien ne le remplace.

La plateforme de démonstration

La plateforme de démonstration se compose de cinq fichiers. La couche interface a été distribuée sur 3 fichiers pour permettre certaines démonstrations spécifiques plus tard dans la série :

• Data — la couche données
• Logic — la couche logique
• Menu — un fichier d’interface et point de coordination principal
• Directory — un fichier d’interface gérant les parties
• Project — un fichier d’interface gérant les projets

Menu est le point d’entrée de la couche interface. Directory et Project opèrent à travers Menu. Directory et Project ne référencent pas Logic directement. Seul Menu détient une référence vers Logic. Le mécanisme de routage est introduit plus tard. La topologie est énoncée au moment où les fichiers sont créés.

Note : la plateforme de démonstration est en anglais. Les noms de fichiers et les identifiants ne sont pas traduits.

Data — inerte par construction

Le fichier Data contient les tables de base. Rien d’autre.

Aucune méthode. Aucune règle de saisie automatique qui calcule des valeurs. Aucun modèle qui écrit dans les données. Aucune suppression en cascade via le graphe de relations — les suppressions sont du comportement, et le comportement appartient aux méthodes. La génération de valeurs structurelles — clés primaires, UUID — est permise. La validation d’unicité est permise — c’est une contrainte d’intégrité des données, pas une règle métier. Le calcul comportemental ne l’est pas.

Le fichier Data stocke ce qui lui est écrit. Il n’exécute aucun comportement.

Ce que cette contrainte exclut, c’est tout comportement qui émerge du schéma plutôt que d’une méthode déclarée. Une règle de saisie automatique qui calcule un statut est du comportement sans propriétaire déclaré. Quand le comportement émerge du schéma, il ne peut pas être rattaché à une méthode — et ne peut donc pas être possédé. La défaillance que cela produit a été documentée dans l’article 3.

La couche Data peut être distribuée sur plusieurs fichiers par domaine ou volume. La nature de chaque fichier ne change pas. Chacun reste inerte, quel que soit leur nombre.

Logic — propriétaire unique du comportement métier

Le fichier Logic contient toutes les règles métier. Toutes les méthodes définissant du comportement métier. Tous les chemins d’exécution. Toute la validation avant persistance. Toutes les écritures dans la couche données.

Le fichier Logic ne sait pas comment l’interface est structurée. Il ne sait pas comment les données seront affichées. Il reçoit une entrée déclarée et retourne un résultat. Le fichier appelant décide quoi faire avec ce résultat.

Ce que cette contrainte exclut, c’est tout autre fichier écrivant dans les tables de base. La propriété du comportement métier est exclusive. Dès qu’un second fichier peut écrire, la propriété est partagée. La mutation distribuée revient.

Les fichiers d’interface n’exécutent pas de comportement métier dans d’autres fichiers d’interface. Tout le comportement métier s’exécute dans le fichier Logic.

Le comportement d’interface peut être orchestré au sein des fichiers d’interface par des méthodes d’interface. Ces méthodes ne contiennent aucune logique métier et ne modifient pas les données.

Menu, Directory, Project — la couche interface

Menu, Directory et Project sont des fichiers d’interface (UI).

Chacun gère la présentation et l’interaction dans son domaine. Chacun collecte l’intention de l’utilisateur, construit une requête, et appelle une méthode. Chacun reçoit un résultat et décide comment l’afficher. Aucun n’applique de règles de validation. Aucun n’écrit dans les tables de base. Aucun ne contient de règle métier.

Directory et Project démontrent une propriété structurelle : la couche interface peut être multipliée sans modifier le fichier Logic. Directory et Project peuvent évoluer indépendamment — présentations redessinées, flux réorganisés, nouveaux modèles ajoutés — sans toucher Logic. Cette indépendance n’est atteignable que parce que ces fichiers ne contiennent aucun comportement propre.

Les fichiers d’interface peuvent exposer des méthodes d’interface (UI methods) destinées uniquement à l’orchestration de l’interface — par exemple, ouvrir un enregistrement dans un autre fichier d’interface. Ces méthodes ne portent aucun comportement métier. Leur rôle est limité à la navigation, à l’affichage et à la coordination entre surfaces d’interface. Elles peuvent réagir à l’état du système à des fins de présentation, mais elles ne déterminent pas les résultats.

Règles d’interaction

La structure de fichiers ne tient que si les interactions entre fichiers sont explicitement définies. La convention n’est pas suffisante. La convention n’impose rien.

Ces règles sont obligatoires :

UI → Logic      autorisé (via Gateway)
UI → Data       autorisé (lecture seule, présentation uniquement — concession à la plateforme, bornée)
Logic → Data    autorisé (lectures et écritures)
Logic → UI      interdit
Inter-fichiers  doit passer par une frontière

Les fichiers d’interface n’appellent pas Logic directement. Ils doivent appeler à travers une frontière — le Gateway (point d’entrée contrôlé). Les mécanismes du Gateway ne sont pas définis ici. Ce qui est établi ici, c’est que la frontière est obligatoire. Un appel direct interface-vers-Logic n’est pas un chemin alternatif. C’est une violation. Tout appel inter-fichiers qui ne passe pas par le Gateway est invalide.

Le fichier Logic est le seul fichier autorisé à écrire dans les tables de base. Les fichiers d’interface peuvent lire depuis la couche Data directement pour la présentation, la navigation et le contexte des modèles. C’est une concession à la plateforme pour préserver les avantages de développement rapide de FileMaker dans la couche interface. Elle ne transfère pas la propriété du comportement métier. Aucune validation, décision ou vérification d’éligibilité ne peut découler de ces lectures. Dès qu’une lecture oriente une décision, elle a quitté le domaine de la présentation et doit passer par Logic.

La direction est à sens unique. Une dépendance dans le mauvais sens n’est pas un problème de style — elle réintroduit une classe spécifique de défaillance.

Si Logic dépend d’un fichier d’interface, le comportement devient conditionnel au contexte de présentation. C’est le couplage implicite de l’article 3, réintroduit par une dépendance inversée. Si Data dépend de Logic, il peut invoquer un comportement. L’inertie est brisée. C’est la mutation non contrôlée, réintroduite par la même erreur directionnelle.

La direction des dépendances n’est pas un choix de conception. Elle découle de ce que chaque couche a le droit de faire.

Concessions à la plateforme

Une concession à la plateforme est une impureté structurelle requise par FileMaker, explicitement contenue, localisée et sans propagation.

La première instance apparaît dans le fichier Logic.

FileMaker requiert un contexte de modèle pour effectuer une écriture dans une table. Le fichier Logic doit donc contenir des modèles vides — pas comme interface, mais comme mécanisme que la plateforme requiert pour exécuter les écritures. Ces modèles ne portent aucune logique de présentation. Leur rôle est déclaré. Leur présence ne se propage pas vers la couche interface ou la couche Data. Ils existent dans Logic, pour Logic, et à aucune autre fin.

La deuxième instance apparaît dans la couche interface.

L’avantage de développement rapide de FileMaker repose sur l’accès direct aux données depuis l’interface — portails, rubriques, contextes de navigation. Faire passer toutes les lectures par Logic rendrait la couche interface impraticable à construire dans FileMaker. Les fichiers d’interface sont donc autorisés à lire depuis la couche Data directement pour la présentation. Cette permission est bornée : elle couvre l’affichage, la navigation et le contexte des modèles. Elle ne s’étend pas à la validation, aux décisions, aux vérifications d’éligibilité, ni à toute règle relevant de la couche métier. La concession existe à la frontière de la présentation. Elle s’arrête là.

La troisième instance apparaît dans le fichier Data.

FileMaker requiert un contexte d’occurence de table pour évaluer tout calcul, même un calcul sans contexte réel — y compris la génération de valeurs structurelles déjà permise dans ce fichier, comme un entrée automatique Get ( UUID ) ou un horodatage calculé. Le fichier Data est donc autorisé à contenir, pour chacune de ses tables de base, l’occurence de table propre à cette table — utilisée exclusivement pour satisfaire cette exigence. Cette permission est bornée : elle couvre uniquement l’occurence de table propre à la table et rien d’autre. Aucune relation. Aucune occurence de table référençant une autre table. Aucune accessibilité au-delà de la table qu’elle représente. Une occurence de table sans relation ne change rien à ce que le fichier peut atteindre ou faire — elle existe pour qu’un calcul déjà permis puisse aboutir, pas pour que le fichier puisse naviguer.

Ce n’est pas une violation du modèle. C’est une concession nommée à une contrainte de plateforme. La distinction est importante : une violation est sans nom et sans limite. Une concession est explicite, localisée et bornée.

Cette catégorie — concession à la plateforme — s’applique partout où FileMaker impose une exigence structurelle que le modèle exclurait autrement. Chaque instance diffère. Le cadre reste le même.

Ce que le squelette change

Avec cette structure en place, la nature d’une violation change.

Dans un espace partagé, une violation est invisible par défaut. Une méthode qui écrit directement dans une table, une règle métier dans un modèle d’interface, une dépendance implicite entre méthodes — rien dans la forme du système ne les distingue des décisions légitimes. Elles coexistent avec le comportement correct dans le même espace, indifférenciées.

Dans un système à fichiers séparés avec des règles d’interaction explicites, une violation devient une décision visible. Placer une méthode dans le fichier Data n’est pas un accident de proximité — c’est un passage délibéré au-delà d’une frontière établie.

La violation n’est pas rendue impossible. Elle est rendue vérifiable.

La structure existe maintenant physiquement.

Les rôles sont assignés. Les règles d’interaction sont énoncées. Les frontières sont définies.

Dans le fichier Logic, l’exécution reste libre. N’importe quelle méthode peut appeler n’importe quelle autre méthode. Les entrées ne sont pas contrôlées. Les sorties ne sont pas garanties. L’état ambiant reste possible. Les contrats implicites restent possibles.

Le problème spatial est résolu. Le problème d’exécution est ouvert.

C’est la prochaine contrainte.

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.