Comment partager le DTO entre les microservices?
Mon scénario est le suivant.
Je suis en train de concevoir un système conçu pour recevoir des données de différents types de capteurs, puis les convertir et les conserver pour les utiliser ultérieurement par divers services frontaux et d'analyse.
J'essaie de concevoir chaque service pour qu'il soit aussi indépendant que possible, mais j'ai des problèmes. L'équipe a décidé d'un DTO que nous aimerions utiliser. Les services tournés vers l'extérieur (destinataires des données des capteurs) recevront les données à leur manière, puis les convertiront en un objet JSON (le DTO) et les enverront au Message Broker. Les consommateurs des messages sauront alors exactement comment lire les messages de données du capteur.
Le problème est que j'utilise le même DTO dans quelques services différents. Une mise à jour doit être implémentée dans plusieurs emplacements. De toute évidence, nous l'avons conçu de telle sorte que quelques champs supplémentaires ou manquants dans le DTO ici et il n'y a pas beaucoup de problème jusqu'à ce que les services aient été mis à jour, mais cela me dérange toujours et me donne l'impression que je suis commettre une erreur. Cela pourrait facilement devenir un mal de tête.
Suis-je en train de mal architecturer le système? Sinon, quels sont les moyens de contourner ce problème, ou du moins de soulager mes inquiétudes?
Mon conseil? Ne partagez pas ces DTO entre les applications de tout type de bibliothèque. Ou du moins, ne faites pas ça maintenant.
Je sais, cela semble très contre-intuitif. Vous dupliquez du code, non? Mais ce n'est pas une règle commerciale, vous pouvez donc être plus flexible.
Le service qui envoie le DTO doit être rigide dans son contrat de message, comme une API Rest. Le service ne peut pas modifier le DTO d'une manière qui pourrait casser les autres services qui consomment déjà les informations du DTO.
Lorsqu'un nouveau champ est ajouté au DTO, vous ne mettez à jour les autres services qui consomment ce DTO que si ils ont besoin du nouveau champ. Sinon, oubliez ça. En utilisant JSON comme type de contenu, vous avez la possibilité de créer et d'envoyer de nouveaux attributs sans casser le code des services qui ne mappent pas ces nouveaux champs sur ses versions réelles de DTO.
Mais si cette situation vous dérange vraiment, vous pouvez suivre la règle des trois :
Il y a deux "règles de trois" dans la réutilisation: (a) il est trois fois plus difficile de construire des composants réutilisables que des composants à usage unique, et (b) un composant réutilisable doit être testé dans trois applications différentes avant qu'il ne soit suffisamment général à accepter dans une bibliothèque de réutilisation.
Essayez donc d'attendre un peu plus avant de partager ce DTO entre les services.
En ce qui concerne les microservices, les services ' cycles de vie du développement devraient également être indépendants.*
Différents SLDC et différentes équipes de développement
dans un véritable système MS, il pourrait y avoir plusieurs équipes impliquées dans le développement de l'écosystème, chacune en charge d'un ou plusieurs services. À leur tour, ces équipes peuvent être situées dans différents bureaux, villes, pays, plan ... Peut-être, elles ne se connaissent même pas, ce qui rend le partage de connaissances ou de code très difficile (si possible). Mais cela pourrait être très pratique car le code partagé implique également une sorte de raisonnement partagé et quelque chose d'important à rappeler est que, tout ce qui a du sens pour une équipe spécifique, n'a pas à le faire pour une autre équipe. Par exemple, étant donné le client DTO , il pourrait être différent selon le service en jeu, car les clients sont interprétés (ou vus ) différemment de chaque service.
Différents besoins, différentes technologies
Les SLDC isolés permettent également aux équipes de choisir la pile qui convient le mieux à leurs besoins. L'imposition de DTO implémentés dans une technologie spécifique limite la capacité de choix des équipes.
Les DTO ne sont ni des règles commerciales ni des contrats de services
Que sont vraiment les DTO? Objets simples sans autre objectif que de déplacer des données d'un côté à l'autre. Sacs de getters et setters. Ce n'est pas le genre de "connaissances" qui mérite d'être réutilisé, dans l'ensemble parce qu'il n'y a aucune connaissance du tout. Leur volatilité en fait également de mauvais candidats au couplage.
Contrairement à ce que Dherik a déclaré, il doit qu'un service puisse changer ses DTO sans avoir à faire changer d'autres services en même temps. Les services doivent être des lecteurs tolérants, des écrivains tolérants et tolérants aux défaillances . Sinon, ils provoquent le couplage de telle manière que l'architecture de service n'a aucun sens. Encore une fois, et contrairement à la réponse de Dherik, si trois services nécessitent exactement les mêmes DTO, il est probable que quelque chose s'est mal passé lors de la décomposition des services.
Différentes affaires, différentes interprétations
Bien qu'il puisse y avoir (et il y aura) des concepts transversaux entre les services, cela ne signifie pas que nous devons imposer un modèle canonique pour forcer tous les services à les interpréter de la même manière.
Étude de cas
Supposons que notre entreprise dispose de trois départements, Service client , Ventes et Expédition . Supposons que chacune de ces versions libère un ou plusieurs services.
Le service client, en raison de son langue du domaine, implémente des services autour du concept de clients, où clients sont personnes . Par exemple, les clients sont modélisés comme nom , nom , âge , sexe , email , téléphone , etc.
Supposons maintenant que Sales et Shipping modélisent également leurs services en fonction de leurs langues de domaine respectives. Dans ces langues, le concept client apparaît également mais avec une différence subtile. Pour eux, les clients ne sont pas (nécessairement) des personnes . Pour les ventes , les clients sont un numéro de document a carte de crédit et un adresse de facturation , pour Expédition a nom complet et a adresse de livraison aussi.
Si nous forçons Sales et Shipping à adopter le modèle de données canonique de Customer Service , nous les forçons à gérer les données inutiles qui pourraient finir par introduire une complexité inutile s’ils doivent conserver la représentation entière et garder les données du client synchronisées avec service client .
Liens connexes
* Voici où réside la force de cette architecture
J'essaie de concevoir chaque service pour qu'il soit le plus indépendant possible
Vous devriez publier événements. Les événements sont certains types de messages qui représentent n fait solide à propos de quelque chose qui s'est produit à un moment donné.
Chaque service devrait avoir une responsabilité très bien définie et devrait avoir la responsabilité de publier les événements liés à cette responsabilité.
De plus, vous voulez que vos événements soient des événements liés à l'entreprise, et non des événements techniques. Par exemple. préférez OrderCancelled événement à un OrderUpdated avec status: "CANCELLED".
De cette façon, lorsqu'un service doit réagir à une commande annulée, il doit simplement écouter ce type de message particulier, qui ne transporte que des données pertinentes pour cet événement. Par exemple. un OrderCancelled a probablement juste besoin d'un order_id. Quel que soit le service qui doit réagir à cela, il a déjà stocké tout ce qu'il doit savoir sur la commande dans son propre magasin de données.
Mais si le service n'avait que OrderUpdated événements à écouter, il aurait besoin d'interpréter le flux d'événements, et il dépendait désormais du bon de livraison pour se terminer correctement lorsqu'une commande était annulée.
Dans votre cas, cependant, comme vous publiez des données de capteur, il peut être judicieux d'avoir un service, d'écouter les événements et de publier un nouveau flux d '"événements commerciaux", par exemple TemperatureThresholdExceeded, TemperatureStabilised.
Et faites attention à ne pas créer trop de microservices. Les microservices peuvent être un excellent moyen d'encapsuler la complexité, mais si vous ne découvrez pas les limites de service appropriées, votre complexité réside dans l'intégration de service. Et c'est un cauchemar à entretenir.
Il vaut mieux avoir trop peu, trop de services, que d'avoir trop, trop petits services.