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 manière 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é lors du DTO, vous ne mettez à jour les autres services qui consomment ce DTO que s'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 les 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 cycles de vie de développement des services doivent é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 des connaissances ou du code très difficile (si possible). Mais cela pourrait être très pratique car le code partagé implique également une sorte de raisonnement de partage 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 , cela peut ê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 être possible pour un service de changer ses DTO sans avoir à effectuer 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 sa langue de domaine , met en œuvre des services autour du concept de clients, où les clients sont des personnes . Par exemple, les clients sont modélisés comme nom , prénom , âge , sexe , e - mail , téléphone , etc.

Supposons maintenant que les services de vente et d' expédition modélisent également leurs services en fonction de la langue de leur domaine respectif. Dans ces langues, le concept client apparaît lui aussi mais avec une subtile différence. Pour eux, les clients ne sont pas (nécessairement) des personnes . Pour les ventes , les clients sont un numéro de document, une carte de crédit et une adresse de facturation , pour l' expédition un nom complet et une adresse de livraison aussi.

Si nous forçons Sales and Shipping à adopter le modèle canonique de données du service client , nous les forçons à traiter les données inutiles qui pourraient finir par introduire une complexité inutile si elles doivent maintenir la représentation entière et maintenir les données client en synchronisation avec le service client. .

Liens connexes

• Microservices et modèle canonique
• Évitez un modèle de données canonique

^{* 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 des événements . Les événements sont certains types de messages qui représentent un fait solide sur 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 souhaitez que vos événements soient des événements liés à l'entreprise, et non des événements techniques. Par exemple, préférez un OrderCancelledévénement à un OrderUpdatedavec status: "CANCELLED".

De cette façon, lorsqu'un service doit réagir à une commande annulée, il a juste besoin d'écouter un type de message particulier, qui ne transporte que des données pertinentes pour cet événement. Par exemple, un a OrderCancelledprobablement 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 des OrderUpdatedévénements à écouter, il devrait alors interpréter le flux des é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 la publication des données sont des capteurs, il serait logique d'avoir un service, écouter les événements et publier un nouveau flux de « événements d'affaires », 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 de 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.