Domaines de valeurs vs Données de référence - Comprendre la différence

Comprendre la différence entre un domaine de valeurs et des données de référence est essentiel lorsqu’on conçoit des systèmes distribués. Ces deux notions touchent à la gestion de la donnée et à sa gouvernance, et saisir leur rôle respectif aide à bâtir des systèmes plus robustes et cohérents.

Cet article m’a été inspiré par une discussion au travail où la majorité des membres autour de la table n’avaient pas la même définition de ces deux termes. Cette divergence montre à quel point la distinction n’est pas toujours évidente, même parmi des professionnels expérimentés, et peut rapidement mener à des incompréhensions dans la conception d’un système.

Nous allons donc explorer ensemble ce que sont un domaine de valeurs et des données de référence, à quoi ils servent, comment les différencier, qui en est responsable, et enfin examiner des exemples et des stratégies pour limiter l’impact de la distribution des données entre services.

Qu’est-ce qu’un domaine de valeurs ?

Un domaine de valeurs représente l’ensemble des valeurs possibles qu’une donnée (ou attribut) peut prendre. En d’autres termes, c’est une liste de valeurs autorisées pour un champ de données donné. Par exemple, si l’on considère un attribut Statut de commande, son domaine de valeurs pourrait être : EnCours, Expédiée, Livrée ou Annulée. Ce concept équivaut à un vocabulaire contrôlé ou à une liste de valeurs permises pour un attribut.

Dans un système d’information, les domaines de valeurs servent à valider et contraindre les données. Ils garantissent l’intégrité en limitant les entrées à un jeu prédéfini de valeurs acceptables. Souvent, ces domaines de valeurs se matérialisent par des énumérations dans le code (par exemple, un enum en C#) ou par des tables de correspondance en base de données. Par exemple, une application .NET pourrait définir un enum DeviseMonetaire qui ne peut valoir que CAD, USD, EUR, etc., reflétant le domaine de valeurs des devises autorisées.

💡 Il est important de noter qu’un domaine de valeurs est une notion conceptuelle, c’est la définition du périmètre des valeurs possibles pour une donnée. La réalisation concrète de ce domaine (c’est-à-dire la liste spécifique des valeurs actuelles) est souvent gérée via les données de référence, surtout lorsque ces valeurs peuvent changer ou doivent être partagées.

Qu’est-ce que des données de référence ?

Les données de référence (reference data) sont les données qui servent à caractériser ou classer d’autres données. Autrement dit, ce sont généralement des listes ou tables de valeurs partagées, stables dans le temps, et communes à plusieurs systèmes. Elles correspondent justement aux contenus des domaines de valeurs : ce sont les valeurs concrètes permises. Par exemple, la liste des codes pays ISO 3166, la liste des devises, les codes postaux, etc., sont des données de référence typiques.

Les données de référence ont plusieurs caractéristiques clés :

• Stabilité relative : elles évoluent rarement et de manière contrôlée. Par exemple, la liste des pays du monde change très peu fréquemment. Cette stabilité signifie qu’on peut les considérer comme semi-statiques ou immuables du point de vue des clients.
• Portée transverse : elles sont souvent utilisées par de nombreuses applications ou services différents. Par exemple, plusieurs microservices peuvent avoir besoin de connaître la liste des devises ou des pays. À ce titre, les données de référence jouent un rôle de vocabulaire commun à l’échelle de l’entreprise.
• Autorité centralisée : idéalement, il existe une source faisant autorité qui gère chaque donnée de référence (par exemple, un service ou module central, ou même un organisme externe dans le cas des normes internationales). Ainsi, on évite que chaque service définisse sa propre version divergente d’une liste de valeurs critique.

En somme, les données de référence fournissent le contenu des domaines de valeurs partagés. Pour reprendre l’exemple précédent, si le domaine de valeurs d’un attribut Devise est l’ensemble des devises valides, la table de référence des devises contiendra les entrées réelles (CAD, USD, EUR, etc.) avec éventuellement des métadonnées (libellé, symbole, taux de change, etc.).

Selon un glossaire de l’architecture des données : “les données de référence correspondent généralement à des domaines de valeurs, des tables de correspondance ou des ontologies”. Cela souligne bien le lien étroit entre le concept de domaine de valeurs et la matérialisation en tant que données de référence.

À quoi servent domaines de valeurs et données de référence ?

Dans le domaine applicatif (microservice individuel), un domaine de valeurs permet de restreindre les données admissibles et de refléter les règles métier. Par exemple, un microservice de gestion des commandes peut avoir un domaine de valeurs pour le statut d’une commande ou les modes de paiement acceptés. Cela sert à assurer la cohérence interne du service : impossible de créer une commande avec un statut inconnu ou un mode de paiement invalide, car ces attributs sont limités à un ensemble de valeurs prédéfinies.

Au niveau transversal (système global), les données de référence servent à harmoniser les données et faciliter les intégrations. Étant partagées par plusieurs composants, elles fournissent un langage commun. Par exemple, si tous les services utilisent les mêmes codes de pays ou les mêmes codes de catégories produit, il devient plus aisé pour eux de communiquer et d’échanger des informations sans ambiguïté. Les données de référence aident aussi à classifier ou qualifier les données transactionnelles (par exemple, assigner une catégorie normalisée à un produit, ou indiquer la devise d’un montant).

En résumé, on utilise les domaines de valeurs et données de référence pour garantir qualité, cohérence et validité des données :

• Les domaines de valeurs (souvent implémentés localement dans un service) assurent la validité des données en entrée et cohérence avec les règles métier spécifiques du service.
• Les données de référence (souvent partagées) assurent que tous les services parlent le même langage pour les informations communes, ce qui améliore la qualité globale des données de l’entreprise.

Différences entre domaine de valeurs et données de référence

Bien que ces concepts soient liés, on peut les différencier sur plusieurs aspects :

• Nature conceptuelle versus concrète : Un domaine de valeurs est le concept ou le cadre des valeurs autorisées pour un attribut. Les données de référence en sont la manifestation concrète, ce sont les éléments de données eux-mêmes qui remplissent ce domaine. Par analogie, si le domaine de valeurs est une règle (“les statuts possibles sont…”), les données de référence sont la liste effective (EnCours, Expédiée, …).
• Portée et réutilisation : Un domaine de valeurs peut être local à un service ou contexte métier. Par exemple, le microservice Commande définit en interne les statuts de commande qu’il gère, ces valeurs lui sont propres. En revanche, les données de référence ont souvent une portée transversale ou organisationnelle. Elles sont partagées par plusieurs applications ou services au sein du système informatique. Par exemple, la liste des pays est partagée entre les services Client (pour les adresses), Commande (pour les adresses de livraison), Paiement (pour les transactions internationales), etc.

• Responsabilité (ownership) : Le domaine de valeurs d’un attribut appartenant à un microservice est généralement sous la responsabilité de ce microservice-même (ou de l’équipe métier correspondante). Ce sont les experts du domaine ou l’équipe de développement de ce service qui décident, par exemple, quels statuts une commande peut avoir.

  En revanche, les données de référence sont souvent gérées par un entité propriétaire dédiée. Cela peut être :

  • un service de référence central (par exemple, un microservice Catalogue qui fournit la liste des produits et catégories à tous les autres, ou un service Géographie qui fournit pays et régions) ;
  • ou un système externe (par exemple, les codes ISO proviennent d’un organisme externe, mais l’entreprise doit tout de même les gérer en interne via un référentiel). Une bonne gouvernance microservices recommande d’établir une stratégie solide de gestion des données de référence pour accompagner la distribution de ces données. Cela implique de savoir qui est responsable de la mise à jour et de la diffusion de chaque référentiel de valeurs partagées.
• Évolution : Les domaines de valeurs et les données de référence sont en général stables, mais leurs évolutions se gèrent différemment. Un domaine de valeurs strictement local peut évoluer au rythme des besoins métier du service (en ajoutant un nouveau statut, par exemple). Ces modifications impliquent souvent des changements de code ou de schéma de base de données dans le microservice.
  Les données de référence, elles, évoluent via un processus maîtrisé, parfois plus centralisé. Par exemple, ajouter un nouveau pays dans la liste ISO requiert de mettre à jour le référentiel central, puis de propager cette information aux services consommateurs. Cela se fait de manière coordonnée pour préserver la cohérence globale. En pratique, on cherche à ce que les données de référence gardent une qualité élevée et uniforme, à travers la maîtrise de leur cycle de vie (d’où l’existence de pratiques comme le Master Data Management (MDM) de référence pour certains référentiels).
• Implémentation technique : Dans une application .NET par exemple, un domaine de valeurs local peut être implémenté simplement via une énumération ou une liste codée en dur, car le service sait quelles valeurs il gère. À l’inverse, une donnée de référence est souvent stockée dans une base de données ou un fichier de configuration partagé, voire exposée via une API REST dédiée par le service qui la possède. On peut retrouver la donnée de référence sous forme de table SQL, de fichier JSON/XML de configuration, etc., séparée du code métier afin de pouvoir la mettre à jour sans redéployer tous les services.

En synthèse, le domaine de valeurs est un concept plus local et conceptuel, tandis que la donnée de référence est globale (ou partagée) et concrète. D’ailleurs, on constate que dans la littérature, on a tendance à dire que si un attribut a un domaine de valeurs précis, alors cette liste de valeurs constitue justement une donnée de référence. La frontière peut donc être subtile : tout dépend si cette liste de valeurs reste confinée à un seul contexte ou si elle devient un référentiel pour l’ensemble du système.

Exemples dans une architecture microservices .NET

Considérons une application distribuée, bâtie sur une architecture microservices avec des services en ASP.NET Core, chacun ayant sa propre base de données (principe Database per service où chaque microservice gère ses données de façon autonome).

Voici quelques exemples concrets de domaines de valeurs et de données de référence dans ce contexte :

• Service Commande : Ce microservice gère les commandes clients. En interne, il définit un domaine de valeurs pour l’attribut Statut d’une commande (par exemple, Créée, EnCours, Expédiée, Livrée, Annulée). C’est un domaine de valeurs propre au service Commande, reflétant son cycle de vie métier. Ces valeurs peuvent être implémentées comme un enum C# OrderStatus. Par ailleurs, le service Commande peut avoir besoin de la liste des Modes de paiement acceptés (carte de crédit, PayPal, virement, etc.) pour valider les paiements. Si cette liste est spécifique à la logique de commande, elle pourrait être gérée localement. Toutefois, si les modes de paiement sont partagés avec un service de Paiement, ils pourraient alors être considérés comme des données de référence partagées.
• Service Produit/Catalogue : Ce service gère le catalogue de produits. Il contient par exemple la liste des Catégories de produit (électronique, habillement, maison, etc.). Ces catégories sont des données de référence classiques car plusieurs services vont les utiliser : le service Produit (pour attribuer une catégorie à chaque produit), le service Recherche ou Recommandation (pour filtrer/parcourir par catégorie), voire le service Reporting (pour des statistiques par catégorie). La liste des catégories produit serait stockée dans le service Catalogue (par exemple dans une table Categories), ce service faisant autorité sur cette donnée. D’un point de vue des autres microservices, Catégorie est un attribut dont le domaine de valeurs est “la liste des catégories valides”, liste fournie par le service Produit/Catalogue via une API ou un événement.
• Service Localisation : Imaginez un microservice dédié aux données géographiques (pays, régions, villes). Ce service héberge la table de référence des pays du monde, avec leur code ISO, nom, etc. Ces données de référence de localisation seront utilisées par tous les autres services qui manipulent des adresses ou des données locales (service Client pour l’adresse du client, service Livraison pour l’adresse de livraison, etc.). Plutôt que chaque service ait sa propre version de la liste des pays, ils consomment celle du service Localisation. Ici, le domaine de valeurs de l’attribut Pays pour une adresse est défini par la donnée de référence centralisée des pays. Le service Localisation est propriétaire de ces données de référence et en assure la mise à jour (par exemple lorsqu’un nouveau pays est reconnu, ou qu’un nom change).
• Service Utilisateur : Ce service gère les comptes utilisateurs. Il peut avoir des domaines de valeurs internes, par exemple pour le type de compte (Admin, Client, Support, …) ou pour l’état du compte (Actif, Inactif, Suspendu). Ces valeurs étant propres à la logique du service Utilisateur, on les traite comme des domaines de valeurs locaux. En revanche, le service Utilisateur pourrait référencer des données de référence externes, par exemple la liste des questions de sécurité standardisées (si on considère cela comme un référentiel commun) ou la liste des langues pour les préférences linguistiques (souvent gérée comme référence globale).

Dans chacun de ces exemples, on voit que la décision de ce qui constitue un domaine de valeurs local ou une donnée de référence partagée dépend de la nécessité de partage et de cohérence à l’échelle du système. Une règle d’or en microservices est que chaque service est maître de sa propre base de données et de ses données métier, et que le partage de données se fait via des API ou des événements, pas via une base commune. Ainsi, si plusieurs services ont besoin d’une même liste de valeurs, on envisage d’en faire des données de référence gérées par un service et consommées par les autres, plutôt que de dupliquer sans synchronisation.

Limiter l’impact des appels inter-services pour les données de référence

Un défi courant en architecture microservices est la consommation intensive de données détenues par un autre service. Par exemple, si le service Commande doit interroger le service Localisation à chaque commande pour valider un code pays, cela peut entraîner une forte latence ou une dépendance excessive au service Localisation.

Plusieurs stratégies existent pour réduire cet impact tout en maintenant la cohérence des données :

• Mise en cache locale : Chaque microservice consommateur peut mettre en cache les données de référence dont il a besoin. Par exemple, au démarrage, le service Commande pourrait charger la liste complète des pays depuis Localisation et la conserver en mémoire (ou dans une cache distribuée) pour valider les adresses sans devoir appeler le service distant à chaque fois. Cela correspond au modèle Cache-Aside, améliorant la performance en réduisant les appels directs et la latence. En .NET, on pourrait utiliser MemoryCache ou une cache Redis distribuée pour stocker temporairement ces données de référence. L’inconvénient est qu’il faut gérer l’expiration ou l’invalidation de la cache pour ne pas utiliser des données obsolètes trop longtemps.
• Réplication par service : Une approche plus radicale, parfois utilisée, est de dupliquer la donnée de référence dans chaque base locale des services concernés. Par exemple, les services Client et Commande pourraient chacun avoir une table Country synchronisée périodiquement avec le service Localisation. Ainsi, les lectures se font localement, éliminant la dépendance en temps réel. La question est alors comment synchroniser ces copies pour qu’elles restent à jour. Des solutions modernes incluent le Change Data Capture (CDC) : capturer les modifications dans la base du service référentiel et les propager vers les autres bases en temps réel via des événements ou des messages. Par exemple, avec Debezium + Kafka, on peut diffuser chaque changement de la table des pays vers les services abonnés pour une mise à jour immédiate. Moins complexe, on peut aussi exposer une API permettant aux services de rafraîchir périodiquement leur copie (par exemple, un endpoint /countries?modifiedSince=… sur Localisation).

  ⚠️ Attention : cette duplication va à l’encontre du principe de source unique de vérité, donc il faut une gouvernance stricte : un service reste le maître des données (par exemple, Localisation est maître des pays) et les autres ne font que conserver une copie en lecture seule. On obtient une consistance éventuelle : il peut y avoir un léger décalage temporel après une mise à jour, mais on accepte ce compromis pour de meilleures performances locales.

• Approche “Reference Data Holder” (service référentiel central optimisé) : Il s’agit d’un service spécialisé qui fournit les données de référence de manière très optimisée pour la consultation par d’autres. Par exemple, un tel service pourrait offrir une API de téléchargement complet du référentiel (afin qu’un client puisse récupérer toutes les données de référence d’un coup et les stocker localement) ou des requêtes filtrées, en plus des appels unitaires classiques. L’idée est de réduire le nombre d’appels réseau en offrant aux consommateurs la possibilité de récupérer efficacement l’ensemble du domaine de valeurs dont ils ont besoin. Ce pattern, parfois appelé Reference Data Holder, préconise de n’autoriser que des opérations de lecture sur ce service (pas de création/modification côté clients). Le service est ainsi le point central de vérité, mais il encourage les consommateurs à embarquer une copie locale pour usage intensif. Un exemple serait une API /api/v1/countries retournant la liste complète des pays, que chaque service client appellerait au démarrage ou lors d’une mise à jour détectée, évitant ainsi des appels répétés pour chaque pays individuellement.
• Combiner cache et notifications d’événements : Une pratique très efficace est d’utiliser une cache locale au service consommateur tout en écoutant les événements de mise à jour émis par le service référentiel. Par exemple, le service Localisation diffuse un événement CountryUpdated lorsqu’une donnée pays change. Le service Client qui a en cache la liste des pays peut consommer cet événement et ainsi invalider ou mettre à jour sa cache en conséquence. Ainsi, la cache est toujours presque à jour. Cette approche utilise l’architecture événementielle pour allier la performance (lecture locale) et la cohérence (notifications de changements).

Chaque stratégie a ses avantages et compromis : la cache locale et la duplication améliorent les performances et la résilience face à l’indisponibilité d’un service tiers, mais introduisent de la duplication de données et la nécessité de gérer la synchronicité des mises à jour. À l’inverse, interroger systématiquement le service de référence garantit des données à jour à 100%, mais au prix d’une latence accrue et d’une dépendance forte (si le service de référence tombe, les fonctionnalités dépendantes tombent aussi). Souvent, un équilibre pragmatique est recherché : par exemple, mettre en cache les données de référence les plus souvent lues en tolérant qu’elles soient rafraîchies toutes les X heures.

Il est également recommandé d’éviter autant que possible les appels synchrones intensifs inter-services en repensant parfois le besoin : si un service A doit constamment connaître une info détenue par B, c’est un signal qu’il faut peut-être rapprocher ces données de A. En microservices, on privilégie le Decoupling mais il faut faire attention à ne pas créer un couplage fort par les données en sous-estimant l’usage intensif. L’approche par événements (publication/abonnement) est souvent plus adaptée pour propager les données de référence aux endroits qui en ont besoin, sans verrouiller les services dans une interaction synchrone.

Conclusion

Domaines de valeurs et données de référence sont deux notions incontournables en conception de systèmes distribués. Le domaine de valeurs définit le cadre des valeurs admissibles pour une information, tandis que la donnée de référence en est l’implémentation concrète, souvent partagée à travers l’organisation. Les deux contribuent à améliorer la qualité, la cohérence et la fiabilité des données : l’un au niveau local (cohérence métier interne), l’autre au niveau global (standardisation interservices).

Dans une architecture microservices .NET, bien gérer ces concepts signifie clarifier qui possède quelle donnée, et comment les services accèdent aux informations dont ils ont besoin sans compromettre ni l’autonomie des services, ni la performance. Une gouvernance efficace des données de référence est essentielle, car les données fondamentales d’entreprise sont consommées partout tout en étant stockées dans des bases locales distinctes.

En différenciant correctement domaines de valeurs et données de référence, on peut mettre en place les bonnes pratiques : centraliser ou synchroniser ce qui doit l’être, limiter les dépendances directes, utiliser caches et événements pour réduire l’impact des appels interservices. L’objectif final est d’avoir un système où chaque microservice est faiblement couplé, mais sémantiquement aligné avec les autres via des référentiels communs maîtrisés. Ainsi, on obtient le meilleur des deux mondes : l’agilité et l’indépendance des microservices, sans sacrifier la cohérence globale des données de l’entreprise.