Domaines de données

À la base, le maillage des données est fondé sur la décentralisation et la distribution de la responsabilité aux domaines. Si vous comprenez vraiment cette partie du processus, vous êtes bien placé pour gérer les données associées et garantir leur précision. Il s’agit du principe de propriété des données orientée domaine.

Pour promouvoir la propriété des données orientée domaine, vous devez d’abord réaliser une décomposition de votre architecture de données. Le fondateur du maillage de données, Zhamak Dehghani, promeut l’approche de conception basée sur le domaine (DDD) du développement logiciel comme méthode utile pour vous aider à identifier vos domaines de données.

La difficulté liée à l’utilisation de cette approche pour la gestion des données est que le cas d’usage d’origine de l’approche de conception basée sur le domaine modélisait des systèmes complexes dans un contexte de développement logiciel. Elle n’a pas été initialement créée pour modéliser les données d’entreprise. Pour les utilisateurs de gestion des données, sa méthode peut sembler abstraite et technique. On constate aussi souvent un manque de compréhension de l’approche de conception basée sur le domaine. Les utilisateurs trouvent ses notions conceptuelles trop difficiles à comprendre, ou essayent de projeter des exemples d’architecture logicielle ou de programmation orientée objet sur leur paysage de données. Cet article propose des conseils pratiques et un vocabulaire clair afin de comprendre et d’utiliser l’approche de conception basée sur le domaine.

Conception basée sur le domaine

Introduite par Eric Evans, la conception basée sur le domaine est une méthode de prise en charge du développement logiciel qui permet de décrire des systèmes complexes pour les grandes organisations. La conception basée sur le domaine est populaire car grand nombre de ses pratiques de haut niveau ont un impact sur les approches modernes de développement de logiciels et d’applications pour des éléments tels que les microservices.

La conception basée sur le domaine différencie les contextes limités, les domaines et les sous-domaines. Les domaines sont des espaces de problème que vous devez résoudre. Ils consistent en des zones où les connaissances, le comportement, les lois et les activités se rassemblent. Vous voyez le couplage sémantique dans les domaines, les dépendances comportementales entre les composants ou les services. Un autre aspect des domaines est la communication. Les membres de l’équipe doivent utiliser un langage que l’ensemble de l’équipe partage afin que tout le monde puisse travailler efficacement. Ce langage partagé est appelé langage omniprésent ou langage de domaine.

Les domaines sont décomposés en sous-domaines pour mieux gérer la complexité. Un exemple courant est la décomposition d’un domaine en sous-domaines qui correspondent chacun à un problème métier spécifique, comme illustré dans Opérationnaliser le maillage de données pour l’IA/ML.

Tous les sous-domaines ne sont pas identiques. Vous pouvez, par exemple, classifier les domaines pour qu’ils soient « de base », « génériques » ou « de prise en charge ». Les sous-domaines de base sont les plus importants. Ils représentent les ingrédients secrets qui rendent une organisation unique. Les sous-domaines génériques ne sont pas spécifiés et sont généralement faciles à résoudre avec des produits hors service. Les sous-domaines de prise en charge n’offrent pas d’avantage concurrentiel, mais sont nécessaires pour maintenir l’exécution d’une organisation, et ne sont généralement pas complexes.

Les contextes limités sont des limites (contextes) logiques. Ils se concentrent sur l’espace de solution : conception des systèmes et des applications. Il s’agit d’une zone où l’alignement de l’espace de solution est judicieux. Dans la conception basée sur le domaine, ils peuvent inclure du code, des conceptions de base de données, et ainsi de suite. Il peut exister un alignement entre les domaines et les contextes limités, mais il n’existe pas de liaison de règle dure entre les deux. Les contextes limités sont techniques par nature et peuvent s’étendre sur plusieurs domaines et sous-domaines.

Recommandations en matière de modélisation de domaine

Si vous adoptez le maillage de données comme concept de démocratisation des données et implémentez le principe de propriété des données orientée domaine pour augmenter la flexibilité, comment cela fonctionne-t-il dans la pratique ? À quoi ressemble une transition entre la modélisation des données d’entreprise et la modélisation de conception basée sur le domaine ? Quelles leçons pouvez-vous tirer de la conception basée sur le domaine pour la gestion des données ?

Créer une décomposition métier fonctionnelle de vos espaces de problèmes

Avant d’autoriser vos équipes à exploiter leurs données de bout en bout, examinez l’étendue et comprenez les espaces de problème que vous essayez de résoudre. Il est important d’effectuer cet exercice d’abord avant de passer aux détails d’une implémentation technique. Lorsque vous définissez des limites logiques entre ces espaces de problèmes, les responsabilités deviennent plus claires et peuvent être mieux gérées.

Examinez votre architecture métier lors du regroupement de vos espaces de problème. Dans l’architecture métier, il existe des fonctionnalités métier (compétences ou capacités) qu’une entreprise possède ou échange pour atteindre un objectif ou un résultat spécifique. Cette abstraction compacte les données, les processus, l’organisation et la technologie dans un contexte particulier, en alignement avec les buts et objectifs stratégiques de votre organisation. Une carte de capacités métier indique quels domaines fonctionnels sont nécessaires pour réaliser votre mission et votre vision.

Vous pouvez afficher la décomposition des capacités d’une société fictive, Tailwind Traders, dans le modèle suivant.

Tailwind Traders doit maîtriser toutes les zones fonctionnelles répertoriées dans la carte des capacités métier pour réussir. Tailwind Traders doit pouvoir vendre des billets dans le cadre des systèmes d’administration des tickets en ligne ou hors connexion, par exemple, ou disposer de pilotes disponibles pour faire voler des avions dans le cadre d’un programme de gestion des pilotes. L’entreprise peut externaliser certaines activités tout en conservant les autres activités au cœur de son entreprise.

Ce que vous observerez dans la pratique est que la plupart de vos employés sont organisés autour des fonctionnalités métier. Les personnes travaillant sur la même capacité métier partagent le même vocabulaire. La même chose est vraie pour vos applications et processus, qui sont généralement bien alignés et étroitement connectés en fonction de la cohésion des activités qu’ils appuient.

Le mappage des fonctionnalités métier est un point de départ idéal, mais l’histoire ne se termine pas ici.

Mapper les fonctionnalités métier sur les applications et les données

Pour mieux gérer votre architecture d’entreprise, alignez vos fonctionnalités métier, vos contextes limités et vos applications. Il est important de suivre certaines règles de base durant ce processus.

Les fonctionnalités métier doivent demeurer au niveau de l’entreprise et rester abstraites. Elles représentent ce que votre organisation fait et ciblent vos espaces de problème. Lorsque vous implémentez une fonctionnalité métier, une réalisation (instance de fonctionnalité) pour un contexte spécifique est créée. Plusieurs applications et composants fonctionnent ensemble dans ces limites dans votre espace de solution pour fournir une valeur métier spécifique.

Les applications et les composants alignés avec une fonctionnalité métier particulière restent découplés des applications alignées avec d’autres fonctionnalités métier, car elles répondent à différentes préoccupations métier. Les contextes limités sont dérivés et exclusivement mappés aux fonctionnalités métier. Ils représentent la limite d’une implémentation de fonctionnalité métier et se comportent comme un domaine.

Si les fonctionnalités métier changent, les contextes limités changent. Vous souhaitez de préférence un alignement total entre les domaines et les contextes limités correspondants, mais comme vous allez l’apprendre dans les sections suivantes, la réalité est souvent différente.

Si nous projetons le mappage des fonctionnalités à Tailwind Traders, les limitations de contextes limités et les implémentations de domaine peuvent ressembler au diagramme suivant.

Dans ce diagramme, la gestion des clients est basée sur une expertise technique et sait donc mieux les données à distribuer dans d’autres domaines. L’architecture interne de la gestion des clients est découplée, ce qui permet à tous les composants d’application de ces limitations de communiquer directement à l’aide d’interfaces et de modèles de données spécifiques à l’application.

Des produits de données et des normes d’interopérabilité claires sont utilisés pour formaliser la distribution des données vers d’autres domaines. Dans cette approche, tous les produits de données s’alignent également sur le domaine et héritent du langage omniprésent, qui est un langage construit et formalisé convenu par les parties prenantes et les concepteurs du même domaine, pour répondre aux besoins de ce domaine.

Domaines supplémentaires à partir de plusieurs réalisations de fonctionnalités

Il est important de reconnaître lors de l’utilisation des cartes de fonctionnalités métier que certaines fonctionnalités métier peuvent être instanciées plusieurs fois.

Par exemple, Tailwind Traders peut avoir plusieurs réalisations (ou implémentations) localisées de la « gestion des bagages et des objets perdus ». Supposons que l’une de leurs activités opère uniquement en Asie. Dans ce contexte, « la gestion des bagages et les objets perdus » est une fonctionnalité déployée pour les avions liés à l’Asie. Un autre secteur d’activité peut cibler le marché européen et, dans ce contexte, une autre fonctionnalité de « gestion des bagages et d’objets perdus » est utilisée. Ce scénario de plusieurs instances peut entraîner plusieurs implémentations localisées à l’aide de différents services technologiques et d’équipes disjointes pour exploiter ces services.

La relation entre la fonctionnalité métier et les instances de fonctionnalité (réalisations) est un-à-plusieurs. C’est pourquoi vous vous retrouvez avec des domaines (ou sous-domaines) supplémentaires.

Rechercher des fonctionnalités partagées et surveiller les données partagées

La façon dont vous gérez les fonctionnalités métier partagées est importante. Vous implémentez généralement des fonctionnalités partagées de manière centralisée, en tant que modèles de service, et les fournissez à différents secteurs d’activité. La « gestion des clients » peut être un exemple de ce type de fonctionnalité. Dans notre exemple sur Tailwind Traders, les secteurs d’activité asiatiques et européens utilisent la même administration pour leurs clients.

Mais comment projeter la propriété des données de domaine sur une fonctionnalité partagée ? De nombreux représentants d’entreprise prennent probablement en compte les clients au sein d’une même administration partagée.

Il existe un domaine d’application et un domaine de données. Votre domaine et votre contexte limité ne s’alignent pas parfaitement du point de vue du produit de données. Vous pouvez à l’inverse affirmer qu’il existe toujours une préoccupation de données unique du point de vue de la fonctionnalité métier.

Pour les fonctionnalités partagées telles que les packages de fournisseurs complexes, les solutions SaaS et les systèmes hérités, il importe d’être cohérent dans votre approche de propriété des données de domaine. Vous pouvez séparer la propriété des données via des produits de données, ce qui peut nécessiter des améliorations de l’application. Dans notre exemple sur la « gestion des clients » de Tailwind Traders, différents pipelines du domaine d’application peuvent générer plusieurs produits de données : un produit de données pour tous les clients liés à l’Asie et un pour tous les clients liés à l’Europe. Dans ce cas, plusieurs domaines de données proviennent du même domaine d’application.

Vous pouvez également demander à vos domaines d’application de créer un seul produit de données qui encapsule les métadonnées pour distinguer la propriété des données en soi. Par exemple, vous pouvez réserver un nom de colonne pour la propriété, en mappant chaque ligne à un domaine de données spécifique.

Identifier les monolithes offrant plusieurs fonctionnalités métier

Faites également attention aux applications qui répondent à plusieurs fonctionnalités métier, que l’on retrouve souvent dans les grandes entreprises et les entreprises traditionnelles. Dans notre exemple de scénario, Tailwind Traders utilise un package logiciel complexe pour faciliter la « gestion des coûts » et « les ressources et le financement ». Ces applications partagées sont des monolithes qui fournissent autant de fonctionnalités que possible, ce qui les rend volumineuses et complexes. Dans ce cas, le domaine d’application doit être plus volumineux. La même chose s’applique à la propriété partagée, dans laquelle plusieurs domaines de données résident dans un domaine d’application.

Modèles de conception pour les domaines alignés sur la source, de redistribution et alignés sur les consommateurs

Lorsque vous mappez vos domaines, vous pouvez choisir un modèle en fonction de la création, de la consommation ou de la redistribution de vos données. Pour votre architecture, vous pouvez concevoir des modèles qui prennent en charge vos domaines en fonction des caractéristiques spécifiques du domaine.

Domaines alignés sur le système source

Les domaines alignés sur le système source sont alignés sur les systèmes sources à l’origine des données. Ces systèmes sont généralement transactionnels ou opérationnels.

Votre objectif est de capturer des données directement à partir de ces systèmes de source de référence. Optimisez les produits de données en lecture à partir de vos domaines de fourniture pour une consommation intensive de données. Facilitez ces domaines à l’aide de services standardisés pour la transformation et le partage des données.

Ces services, qui incluent des structures de conteneur préconfigurées, permettent à vos équipes de domaine orientées source de publier plus facilement des données. Il s’agit du chemin le moins résistant avec une perturbation et un coût minimes.

Domaines alignés sur les consommateurs

Les domaines alignés sur les consommateurs sont l’opposé des domaines alignés sur la source. Ils sont alignés sur des cas d’usage spécifiques d’utilisateur final qui nécessitent des données provenant d’autres domaines. Les domaines alignés sur les clients consomment et transforment des données pour s’adapter aux cas d’usage de votre organisation.

Envisagez d’offrir des services de données partagés pour la transformation et la consommation des données afin de répondre à ces besoins de consommation. Vous pouvez offrir des fonctionnalités d’infrastructure de données indépendantes du domaine, par exemple, pour gérer les pipelines de données, l’infrastructure de stockage, les services de streaming, le traitement analytique, etc.

Domaines de redistribution

La réutilisation des données représente un scénario différent et plus difficile. Par exemple, si les consommateurs en aval sont intéressés par une combinaison de données provenant de différents domaines, vous pouvez créer des produits de données qui agrègent des données ou combinent des données de haut niveau requises par de nombreux domaines. Cela vous permet d’éviter le travail répétitif.

Ne créez pas de dépendances fortes entre vos produits de données et vos cas d’usage analytiques. Privilégiez la flexibilité et le couplage faible à la place. Le modèle suivant montre comment obtenir de la flexibilité. Un domaine prend possession des produits de données et des cas d’usage analytiques, et a conçu des processus distincts pour la création de produits de données et l’utilisation des données.

Définir des modèles de domaine qui se chevauchent

La modélisation de domaine se complique souvent lorsque les données ou la logique métier sont partagées entre les domaines. Dans les organisations à grande échelle, les domaines s’appuient souvent sur des données provenant d’autres domaines. Il peut être utile de disposer de domaines génériques qui fournissent une logique d’intégration d’une manière qui permet à d’autres sous-domaines de normaliser et d’en tirer parti. Conservez votre modèle partagé entre les petits sous-domaines et toujours aligné avec le langage omniprésent.

Pour les besoins en données qui se chevauchent, vous pouvez utiliser différents modèles à partir de la conception basée sur le domaine. Voici un bref résumé des modèles que vous pouvez choisir :

• Un modèle chemins distincts peut être utilisé si vous préférez le coût associé de la duplication par rapport à celui de la réutilisation. La réutilisation est sacrifiée pour une flexibilité et une agilité plus élevées.
• Un modèle client-fournisseur peut être utilisé si un domaine est fort et prêt à prendre possession des données et des besoins des consommateurs en aval. Les inconvénients incluent notamment les préoccupations conflictuelles et le fait que les équipes en aval sont forcées de négocier les livrables et de planifier les priorités.
• Un modèle partenariat peut être utilisé lorsque votre logique d’intégration est coordonnée de manière non planifiée dans un domaine nouvellement créé. Toutes les équipes collaborent et respectent les besoins des uns et des autres. Étant donné que personne ne peut modifier librement la logique partagée, un engagement significatif est nécessaire de la part de toutes les personnes impliquées.
• Un modèle conformiste peut être utilisé pour conformer tous vos domaines à toutes les exigences. Utilisez ce modèle lorsque votre travail d’intégration est complexe, aucune autre partie ne peut avoir de contrôle, ou que vous utilisez des packages de fournisseur.

Dans tous les cas, vos domaines doivent respecter vos normes d’interopérabilité. Un domaine de partenariat qui produit de nouvelles données pour d’autres domaines doit exposer leurs produits de données comme n’importe quel autre domaine, y compris en prendre possession.

Responsabilités des domaines

Le maillage de données décentralise la propriété des données en la distribuant entre les équipes de domaine. Pour de nombreuses organisations, cela entraîne le passage d’un modèle centralisé autour de la gouvernance à un modèle fédéré. Les équipes de domaine se voient attribuées des tâches, telles que :

• La prise de possession des pipelines de données, tels que l’ingestion, le nettoyage et la transformation des données, pour répondre à autant de besoins du client de données que possible
• L’amélioration de la qualité des données, y compris l’adhésion aux contrats SLA et aux mesures de qualité définies par les consommateurs de données
• L’encapsulation des métadonnées ou l’utilisation de noms de colonne réservés pour les lignes à granularité fine et le filtrage au niveau des colonnes
• Le respect des normes de gestion des métadonnées, notamment :
  • L’inscription du schéma du système source et de l’application
  • Les métadonnées pour une meilleure détectabilité
  • Les informations de contrôle de version
  • La liaison des attributs de données et des termes métier
  • L’intégrité des informations de métadonnées pour permettre une meilleure intégration entre les domaines
• Le respect des normes d’interopérabilité des données, notamment les protocoles, les formats de données et les types de données
• La fourniture de la traçabilité en liant les systèmes sources et les services d’intégration aux scanneurs ou en assurant manuellement la traçabilité
• L’adhésion aux tâches de partage de données, y compris les révisions d’accès IAM et la création du contrat de données

Niveau de granularité pour le découplage

Maintenant que vous savez comment reconnaître et faciliter les domaines de données, vous pouvez apprendre à concevoir le niveau approprié de granularité et de règles de domaine pour le découplage. Deux dimensions importantes sont en jeu lorsque vous décomposez votre architecture.

La granularité des domaines fonctionnels et la définition de contextes limités constituent la première dimension. Les domaines sont conformes à un mode de travail particulier, qui garantit que les données sont disponibles pour tous les domaines utilisant des services partagés, en prenant possession des données, en respectant les normes de métadonnées, etc.

Définissez des limites à granularité fine, si possible, pour la distribution des données. Être piloté par les données consiste à rendre les données disponibles pour une réutilisation intensive. Si vous relâchez vos limites, vous forcez les couplages non souhaités entre de nombreuses applications et perdez la réutilisation des données. Essayez le découplage chaque fois que les données dépassent les limites des fonctionnalités métier. Dans un domaine, un couplage étroit est autorisé au sein de l’architecture interne du domaine. Toutefois, lors du franchissement des limites des fonctionnalités métier, les domaines doivent rester découplés et distribuer des produits de données optimisés en lecture pour le partage avec d’autres domaines.

La granularité des domaines techniques et de l’utilisation de l’infrastructure représente l’autre dimension importante. Vos zones d’atterrissage de données permettent une plus grande agilité pour la maintenance des applications de données, qui créent des produits de données. Comment créer ce type de zone d’atterrissage avec une infrastructure et des services partagés en dessous ? Les domaines fonctionnels sont regroupés logiquement et constituent de bons candidats pour partager l’infrastructure de plateforme. Voici quelques facteurs à prendre en compte lors de la création de ces zones d’atterrissage :

• La cohésion et l’efficacité lors de l’utilisation et du partage de données constituent un moteur fort de l’alignement des domaines fonctionnels sur une zone d’atterrissage des données. Cela concerne la gravité des données, la tendance à partager constamment des produits de données volumineux entre domaines.
• Les limites régionales peuvent entraîner l’implémentation de zones d’atterrissage de données supplémentaires.
• La propriété, la sécurité ou les limites légales peuvent forcer la séparation des domaines. Par exemple, certaines données ne peuvent pas être visibles par d’autres domaines.
• La flexibilité et le rythme des modifications sont des facteurs importants. Certains domaines peuvent disposer d’une vélocité d’innovation élevée, tandis que d’autres domaines ont une stabilité de valeur forte.
• Les limites fonctionnelles peuvent séparer les équipes. Il peut s’agir par exemple de limites orientées source et orientées consommateurs. La moitié de vos équipes de domaine peuvent valoriser certains services par rapport à d’autres.
• Si vous souhaitez vendre ou séparer votre capacité, vous devez éviter d’intégrer étroitement les services partagés à partir d’autres domaines.
• La taille de l’équipe, les compétences et la maturité peuvent tous représenter des facteurs importants. Les équipes hautement qualifiées et matures préfèrent souvent exploiter leurs propres services et infrastructures, tandis que les équipes moins matures sont moins susceptibles de mettre en valeur la surcharge supplémentaire de la maintenance de la plateforme.

Avant de provisionner de nombreuses zones d’atterrissage de données, examinez la décomposition de votre domaine et déterminez quels domaines fonctionnels constituent de bons candidats pour le partage de l’infrastructure sous-jacente.

Récapitulatif

La modélisation des fonctionnalités métier vous permet de mieux reconnaître et d’organiser vos domaines dans une architecture de maillage de données. Elle fournit une vue holistique de la façon dont les données et les applications fournissent de la valeur à votre entreprise, tout en vous aidant à prioriser et à vous concentrer sur votre stratégie de données et vos besoins métier. Vous pouvez également utiliser la modélisation des fonctionnalités métier à d’autres fins que les données. Par exemple, si la scalabilité constitue un problème, vous pouvez utiliser ce modèle pour identifier vos fonctionnalités de base les plus critiques et développer une stratégie pour ces dernières.

Certains utilisateurs soulèvent l’inquiétude que la création d’une architecture d’état cible en mappant tout en amont représente un exercice intensif. Ils vous suggèrent plutôt d’identifier vos domaines de manière organique pendant que vous les intégrez à votre nouvelle architecture de maillage de données. Au lieu de définir votre état cible de haut en bas, travaillez en bas en haut, en explorant, en testant et en passant votre état actuel vers un état cible. Bien que cette approche proposée soit plus rapide, elle présente un risque important. Vous pouvez facilement vous trouver au milieu d’un déplacement ou d’une opération de remodelage complexe lorsque les systèmes commencent à tomber en panne. Travailler à partir des deux directions, de haut en bas et de bas en haut, puis se réunir au milieu sur la durée, constitue une approche plus nuancée.

Étape suivante

• Qu’est-ce qu’un produit de données ?