Domaines de données
Le maillage de données est fondamentalement basé sur la décentralisation et la distribution de la responsabilité aux domaines. Si vous comprenez vraiment une partie de l’entreprise, vous êtes mieux positionné pour gérer les données associées et garantir sa 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 décomposer votre architecture de données. Le fondateur du maillage de données, Zhamak Dehghani, promeut l’approche Domain-Driven Design (DDD) du développement logiciel comme méthode utile pour vous aider à identifier vos domaines de données.
La difficulté avec l’utilisation de DDD pour la gestion des données est que le cas d’usage d’origine de DDD modélisait des systèmes complexes dans un contexte de développement logiciel. Elle n’a pas été créée à l’origine pour modéliser les données d’entreprise, et pour les professionnels de la gestion des données, sa méthode peut être abstraite et technique. On constate souvent un manque de compréhension de l’approche de conception basée sur le domaine. Les praticiens trouvent ses notions conceptuelles trop difficiles à saisir ou à essayer de projeter des exemples d’architecture logicielle ou de programmation orientée objet sur leur paysage de données. Cet article vous fournit des conseils pragmatiques et un vocabulaire clair pour vous permettre de comprendre et d’utiliser DDD.
Conception pilotée par le domaine
Introduit par Eric Evans, Domain-Driven Design est une méthode de prise en charge du développement de logiciels qui permet de décrire des systèmes complexes pour les grandes organisations. DDD est populaire, car la plupart de ses pratiques générales ont un impact sur les approches de développement de logiciels et d’applications modernes, telles que les microservices.
DDD différencie les contextes délimités, les domaines et les sous-domaines. Les domaines sont des espaces de problème que vous souhaitez résoudre. Ce sont des domaines où les connaissances, le comportement, les lois et les activités se réunissent. 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 une langue 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 Operationalize data mesh for AI/ML.
Tous les sous-domaines ne sont pas les mêmes. Vous pouvez, par exemple, classifier des domaines en tant que cœur, générique ou de soutien. Les sous-domaines principaux sont les plus importants. C’est la sauce secrète, les ingrédients, qui rendent une organisation unique. Les sous-domaines génériques sont non spécifiques et généralement faciles à résoudre avec des produits hors-vente. La prise en charge des sous-domaines n’offre pas d’avantage concurrentiel, mais sont nécessaires pour maintenir l’exécution d’une organisation et ne sont pas complexes.
Les contextes délimités sont des limites logiques (contexte). Ils se concentrent sur l’espace de solution : la conception de systèmes et d’applications. Il s’agit d’une zone où l’alignement du focus sur l’espace de solution est logique. Dans DDD, cela peut inclure du code, des conceptions de base de données, et ainsi de suite. Entre les domaines et les contextes délimités, il peut y avoir un alignement, mais il n’existe pas de règle stricte liant 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 que vous implémentez le principe de propriété des données orientée domaine pour accroître la flexibilité, comment cela fonctionne-t-il en pratique ? À quoi pourrait ressembler une transition de la modélisation des données d’entreprise à la modélisation pilotée par le domaine ? Quelles leçons pouvez-vous tirer de DDD pour la gestion des données ?
Créer une décomposition fonctionnelle de vos espaces de problème
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 avant de passer aux détails d’une implémentation technique. Lorsque vous définissez des limites logiques entre ces espaces de problème, 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 capacités métier : capacités ou capacités qu’une entreprise possède ou échange pour atteindre un objectif ou un résultat spécifique. Cette abstraction packe les données, les processus, l’organisation et la technologie dans un contexte particulier, conformément aux objectifs et objectifs stratégiques de votre organisation. Une carte des capacités métier montre quels domaines fonctionnels semblent nécessaires pour remplir 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 business Capability Map pour réussir. Tailwind Traders doit être en mesure de vendre des billets dans le cadre des systèmes de gestion des tickets en ligne ou hors connexion, par exemple, ou avoir des pilotes disponibles pour voler des avions dans le cadre d’un programme de gestion des pilotes. L’entreprise peut externaliser certaines activités tout en conservant d’autres en tant que cœur de son activité.
Ce que vous observez dans la pratique est que la plupart de vos personnes sont organisées autour des fonctionnalités métier. Les personnes travaillant sur les mêmes fonctionnalités métier partagent le même vocabulaire. Il en va de même de vos applications et processus, qui sont généralement bien alignés et étroitement liés en fonction de la cohésion des activités qu’ils appuient.
Le mappage des capacités métier est un excellent point de départ, mais votre histoire ne se termine pas ici.
Associer les fonctionnalités métier aux applications et aux données
Pour mieux gérer votre architecture d’entreprise, alignez vos fonctionnalités métier, les contextes limités et les applications. Il est important de suivre certaines règles de base dans ce que vous faites.
Les fonctionnalités métier doivent rester au niveau de l’entreprise et rester abstraites. Ils représentent ce que fait votre organisation et ciblent vos espaces de problème. Lorsque vous implémentez une fonctionnalité métier, une réalisation (instance de capacité) 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érents problèmes métier. Les contextes limités sont dérivés des capacités métiers et leur sont exclusivement associés. Ils représentent la limite d’une implémentation de capacité métier et se comportent comme un domaine.
Si les fonctionnalités métier changent, les contextes limités changent. Vous vous attendez de préférence à un alignement complet entre les domaines et les contextes délimités correspondants, mais comme vous l’apprenez dans les sections ultérieures, la réalité diffère parfois de l’idéal.
Si nous projetons le mappage des capacités à Tailwind Traders, les limites de contexte limitées et les implémentations de domaine peuvent ressembler au diagramme suivant.
Dans ce diagramme, la gestion des clients repose sur l’expertise en matière et sait donc mieux quelles données servir à d’autres domaines. L’architecture interne de Customer Management est découplée, de sorte que tous les composants d’application au sein de ces limites peuvent communiquer directement à l’aide d’interfaces et de modèles de données spécifiques à l’application.
produits de données et des normes d’interopérabilité claires sont utilisées 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 localisées (ou implémentations) de « gestion des bagages et objets perdus ». Supposons qu’une seule ligne de leurs activités ne fonctionne qu’en Asie. Dans ce contexte, « la gestion des bagages et les objets perdus » est une fonction assurée pour les vols à destination de l'Asie. Une autre gamme d’entreprises peut cibler le marché européen, et dans ce contexte, une autre fonctionnalité de « gestion des bagages et d’éléments 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 équipes disjointes pour exploiter ces services.
La relation entre la capacité métier et les instances de capacité (réalisations) est une relation de un à plusieurs. En raison de cela, vous vous retrouvez avec des domaines supplémentaires (sous-domaines).
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. En règle générale, vous implémentez des fonctionnalités partagées de manière centralisée, en tant que modèles de service et fournissez-les à différents secteurs d’activité. La « gestion des clients » peut être un exemple de ce type de fonctionnalité. Dans notre exemple Tailwind Traders, les lignes d’affaires asiatiques et européennes utilisent la même administration pour leurs clients.
Mais comment projeter la propriété des données de domaine sur une fonctionnalité partagée ? Plusieurs représentants d’entreprise prennent probablement la responsabilité des clients au sein de la 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 unique en matière de données du point de vue des capacités 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, soyez cohérentes 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 d’application. Dans notre exemple Tailwind Traders « Customer Management », 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 asiatiques et un pour tous les clients européens. 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 produit de données unique qui encapsule les métadonnées pour distinguer la propriété des données en soi. Vous pouvez, par exemple, réserver un nom de colonne pour la propriété, mapper chaque ligne à un domaine de données spécifique.
Identifier les monolithes offrant plusieurs fonctionnalités métier
Faites attention également aux applications qui répondent à plusieurs fonctionnalités métier, qui sont souvent vues dans les grandes et les entreprises traditionnelles. Dans notre exemple de scénario, Tailwind Traders utilise un package logiciel complexe pour faciliter à la fois la « gestion des coûts » et les « actifs et le financement ». Ces applications partagées sont des monolithes qui fournissent autant de fonctionnalités que possible, ce qui les rend volumineux et complexes. Dans ce cas, le domaine d’application doit être plus grand. 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 réexpédition 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 redéliverie 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 dont les données proviennent. 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 d’or. Produits de données optimisés pour la lecture issus de vos domaines de fourniture destinés à une consommation intensive des 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. C’est le chemin de la moindre résistance avec une perturbation et un coût minimes.
Domaines alignés sur les consommateurs
Les domaines alignés sur les consommateurs sont opposés aux domaines alignés sur la source. Ils sont alignés sur des cas d’usage spécifiques de l’utilisateur final qui nécessitent des données provenant d’autres domaines. Les domaines alignés sur le client consomment et transforment des données pour répondre 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, et ainsi de suite.
Domaines de redistribution
La réutilisation des données est 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 combiner 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 les cas d’usage analytiques. Privilégiez la flexibilité et le couplage faible à la place. Le modèle suivant montre comment vous pouvez obtenir une 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 est souvent compliquée 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 d’avoir des domaines génériques qui fournissent une logique d’intégration d’une manière qui permet à d’autres sous-domaines de normaliser et de tirer parti de celui-ci. Conservez votre modèle partagé entre les petits sous-domaines et toujours aligné sur la langue omniprésente.
Pour les besoins en données qui se chevauchent, vous pouvez utiliser différents modèles de la conception pilotée par le domaine. Voici un bref résumé des modèles parmi lesquels 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 les préoccupations conflictuelles et forcer vos équipes en aval à négocier des livrables et planifier des priorités.
- Un partenariat modèle 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 changer librement la logique partagée, un engagement significatif est nécessaire de la part de tous les participants.
- Un modèle conforme peut être utilisé pour adapter tous vos domaines à toutes les exigences. Utilisez ce modèle lorsque votre travail d’intégration est complexe, qu’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 prendre possession.
Responsabilités de domaine
Le maillage de données décentralise la propriété des données en la répartissant entre les équipes de domaine. Pour de nombreuses organisations, cela signifie un passage d’un modèle centralisé autour de la gouvernance à un modèle fédéré. Les équipes de domaine sont affectées à des tâches, telles que :
- Prise en charge des pipelines de données, tels que l’ingestion, le nettoyage et la transformation des données, pour servir autant de clients de données que possible
- Amélioration de la qualité des données , y compris l’adhésion aux SLA et des mesures de qualité établies par les consommateurs de données
- Encapsuler des métadonnées ou utiliser des noms de colonnes réservés pour le filtrage au niveau granulaire des lignes et des colonnes
- Respect des normes de gestion des métadonnées, notamment :
- Respect des normes d’interopérabilité des données, notamment les protocoles, les formats de données et les types de données
- Fournir une traçabilité en liant les systèmes sources et les services d’intégration aux scanneurs ou en fournissant manuellement la traçabilité
- Respect des tâches de partage de données, notamment les révisions d’accès IAM et la création de contrats 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 de granularité et les règles de domaine appropriés pour le découplage. Deux dimensions importantes sont en jeu lorsque vous décomposez votre architecture.
La granularité pour les domaines fonctionnels et la définition de contextes limités est une dimension. Les domaines sont conformes à un mode de fonctionnement particulier, ce qui garantit que les données sont disponibles pour tous les domaines à l’aide de services partagés, en prenant possession, en respectant les normes de métadonnées, etc.
Définissez les limites affinées si possible pour la distribution des données. Devenir 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 indésirables entre de nombreuses applications et perdez la réutilisabilité des données. Essayez de découpler chaque fois que les données dépassent les limites des fonctionnalités métier. Dans un domaine, un couplage étroit dans l’architecture interne du domaine est autorisé. Toutefois, lorsque vous franchissez les 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 est l’autre dimension importante. Vos zones d’atterrissage de données permettent une 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 sont de bons candidats au partage de 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 sont un moteur fort de l’alignement des domaines fonctionnels sur une zone d’atterrissage de données. Cela concerne la gravité des données, la tendance à partager constamment des produits de données volumineux entre des 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 changements sont des facteurs importants. Certains domaines peuvent avoir une innovation rapide, tandis que d’autres valorisent fortement la stabilité.
- Les limites fonctionnelles peuvent séparer les équipes. Par exemple, il peut s’agir de limites orientées vers la source et orientées vers les consommateurs. La moitié de vos équipes de domaine peut valoriser certains services par rapport à d’autres.
- Si vous souhaitez éventuellement vendre ou séparer votre capacité, vous devez éviter d’intégrer étroitement les services partagés à partir d’autres domaines.
- La taille, les compétences et la maturité de l’équipe peuvent tous être 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 valoriser la surcharge supplémentaire de 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 sont les candidats au partage de l’infrastructure sous-jacente.
Résumé
La modélisation des capacités métier vous permet de mieux reconnaître et d’organiser vos domaines dans une architecture de maillage de données. Il 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 à hiérarchiser 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 pour plus que des données. Par exemple, si l’extensibilité est 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 eux.
Certains praticiens soulèvent l’inquiétude que la création d’une architecture d’état cible en mappant tout à l’avance est 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 du haut vers le bas, vous travaillez de bas en haut, en explorant, expérimentant, et en faisant passer votre état actuel à un état cible. Bien que cette approche proposée soit plus rapide, elle présente un risque important. Vous pouvez facilement être au milieu d’un déplacement complexe ou d’une opération de remodelage lorsque les choses commencent à se briser. Travailler dans les deux directions, de haut en bas et de bas en haut, puis se rencontrer au milieu avec le temps est une approche plus nuancée.