Isomorphismes aux frontières : traduction sans perte d’information

Un isomorphisme entre deux types $A$ et $B$ est une paire de fonctions $\text{to} : A \to B$ et $\text{from} : B \to A$ telles que $\text{from}(\text{to}(a)) = a$ et $\text{to}(\text{from}(b)) = b$ pour toute valeur.

Autrement dit, on peut convertir dans un sens puis dans l’autre sans perdre d’information : les deux types sont structurellement équivalents, simplement habillés différemment. Aux frontières des applications, là où les données traversent des membranes entre systèmes hétérogènes, cette notion devient un outil conceptuel précieux pour raisonner sur la fidélité des transformations.

Les frontières multiples d’une application

Les frontières d’une application sont multiples, notamment :

• API HTTP recevant du JSON
• Lecture de fichiers CSV
• Communication avec une base de données
• Appels à des services externes
• Sérialisation pour le cache

À chaque traversée, les données changent de représentation : d’objets mémoire vers du texte, de texte vers des structures typées, d’un schéma vers un autre.

L’idéal est que ces transformations soient isomorphiques : ce qui sort peut être reconstruit à l’identique à l’entrée. Quand cet idéal est atteint, on a la garantie qu’aucune information métier n’est corrompue ou perdue lors du transit. Une corruption de données aux frontières détruit la confiance client : un montant tronqué, une date décalée, un identifiant altéré peuvent transformer une transaction anodine en litige coûteux.

Isomorphismes partiels et injections

En pratique, les isomorphismes parfaits sont rares aux frontières réelles :

• JSON ne distingue pas les entiers des flottants
• XML impose un ordre aux éléments que notre domaine ignore peut-être
• Les bases relationnelles aplatissent les structures imbriquées

On travaille alors avec des isomorphismes partiels ou des injections : la transformation to préserve toute l’information, mais from n’est définie que sur l’image de to.

Reconnaître explicitement ces limitations guide le design. Si notre type domaine contient des distinctions que le format cible ne peut pas représenter, soit on enrichit le format, soit on accepte consciemment la perte, soit on repense le type source.

Lien avec “Parse, don’t validate”

L’approche Parse, don’t validate s’inscrit naturellement dans ce cadre.

Le parsing à la frontière entrante tente de construire un isomorphisme partiel : depuis le type large et non fiable (unknown, string, JSON brut) vers le type domaine précis. Si la donnée entrante n’appartient pas à l’image attendue, le parsing échoue explicitement.

La sérialisation sortante constitue l’autre direction : du type domaine vers un format transmissible. Quand ces deux directions sont inverses l’une de l’autre, on a un codec (un isomorphisme encapsulé) et les tests de propriété peuvent vérifier automatiquement l’aller-retour (round-trip) :

$\text{decode}(\text{encode}(x)) = x$

et ce pour toute valeur $x$ du domaine.

A noter qu’une telle propriété de round-trip est utile en property-based testing. Ces tests sont une assurance peu coûteuse : détecter une perte de données en CI coûte quelques minutes de correction, la détecter en production coûte des heures d’investigation, des données à réconcilier, parfois des compensations clients.

Discipline architecturale

Cette perspective isomorphique encourage une discipline architecturale saine.

Elle pousse à définir des types canoniques au cœur du domaine, indépendants de toute représentation externe, puis à maintenir des couches de traduction explicites vers chaque format périphérique. C’est essentiel dans les architectures ports & adapter (hexagonal) ou clean architecture par exemple.

Chaque couche de traduction devient testable isolément : on vérifie le round-trip, on vérifie la gestion des cas d’erreur. Les évolutions de schéma (nouveaux champs, types modifiés, versions d’API) se négocient dans ces couches de traduction plutôt que de contaminer le domaine.

Pour le versioning d’API, des transformations réversibles permettent de faire évoluer les formats sans casser les clients existants : on peut supporter plusieurs versions simultanément, migrer progressivement, et maintenir des relations commerciales durables avec les intégrateurs.

L’isomorphisme, même quand il n’est qu’un idéal approché, fournit un critère de qualité objectif : plus nos transformations s’en rapprochent, plus nos échanges de données sont fiables.