J'ai donc lu des bibliothèques partagées dans micorsevrice ae bad, car elles ne permettent pas une autonomie complète du service pour évoluer.
Et exemple:
Service A and Service B both talk to Service C to view some data.
Je peux créer les objets de domaine dans chaque service et copiez le code du service C.
OU
Je peux partager une bibliothèque partagée entre les services.
Maintenant, je sais si J'ai besoin de modifier la bibliothèque partagée, il faut à nouveau déployer les 3 services.
MAIS
Si je duplique du code et que je trouve un bogue dans le code d'origine, je dois encore déployer les 3 services au fur et à mesure que le code est copié, il y a donc toujours un effet d'entraînement.
Alors, pourquoi le partage est-il si mauvais, dans mon exemple?
4 Réponses :
Si vous copiez le service aux deux endroits au lieu de l'utiliser directement à partir de la même source qui partage toujours. Cela ne permet toujours pas l'autonomie, comme vous l'avez correctement souligné.
Vous devez repenser les 3 services pour ne plus avoir cette dépendance conceptuelle . Je soupçonne que cette dépendance est là parce que vous avez des "données" dont A et B ont besoin que C a. Au lieu de cela, essayez de proposer un autre type de division où les services offrent des fonctionnalités (et non des données) qu'ils peuvent eux-mêmes remplir sans d'autres services.
Ce n'est certes pas toujours facile, mais c'est ce qui se cache derrière cette politique "ne pas partager la logique métier".
C'est un commentaire valide, mais les données que je souhaite partager sont communes dans divers contextes délimités, le service A, B étant l'un, un autre pourrait être le service X et Y. Cela me laisse donc avec le même problème .. Je suis prêt à accepter le partage approche du noyau à cela, puisque nous avons une équipe gérant tous les services (contextes limités)
Je ne connais évidemment pas votre cas d'utilisation. Mais. Un contexte borné signifie qu'il a des limites. Comme dans, il existe une frontière claire entre les concepts à l'intérieur et à l'extérieur. Le partage de données est par définition des concepts de partage, ce qui signifie qu'il n'est pas du tout limité. Erreurs habituelles de contextes illimités: conception de «microservices» CRUD, comme les clients, les commandes, les produits, des choses comme ça. Je dois revenir sur: vous ne voulez pas partager de données. Si vous faites cela, les dominos commencent à tomber et vous ferez face à des problèmes conceptuels comme celui que vous avez publié.
Je ne suis pas sûr de partager des concepts, car un contexte limité ne signifie pas que vous ne pouvez pas partager un concept, c'est le sens que vous donnez à ce concept qui est la limite, un service client à commander a un sens différent pour le client et pour un service comptable. J'accepte aussi qu'un système ne peut jamais être un système parfait. oui, le cas d'utilisation pour moi fait des données partagées une exigence dans le système whoel ... et la duplication ne fonctionne pas bien ...
Dans votre exemple, le partage est mauvais parce que vous recoulez ce que vous avez découplé.
Le service A et le service B parlent tous deux au service C pour afficher certaines données.
Si les services A et B utilisent une bibliothèque partagée, les changements de l'équipe B affectent également le service de l'équipe A. Peut-être que l'équipe A n'est pas au courant des changements ou que les changements sont simplement adaptés au service B.
Mais le concept de partage n'est pas mal, il faut sûrement accepter des exceptions à la règle ... DDD a le noyau partagé?
Les principaux objectifs des microservices sont de créer des services évolutifs faiblement couplés qui peuvent être modifiés indépendamment des autres services. La création de nos bibliothèques partagées ou objets de domaine crée un couplage entre les projets.
Les développeurs de microservices doivent comprendre la réalité selon laquelle duplication de code entre microservices
Commencez par concevoir un monocytaire, puis divisez votre code dans un contexte borné.
Le contexte borné définit les limites des plus grands services possibles: des services qui n'auront pas de modèles en conflit à l'intérieur, donc le contexte borné est une projection dans l'espace de solution pour définir les limites dans le système implémentant le domaine.
Règle de base un contexte limité = un microservice avec une seule responsabilité.
Toujours rappeler que l'accent ne doit pas être mis sur la taille mais sur les capacités commerciales.
Si vous avez besoin de partager votre domaine entre des services, vous avez donc créé des services Nano au lieu d'un microservice et que le service Nano est anti-modèle.
Le contexte borné définit la frontière entre les concepts du système, concepts qui sont définis par le langage omniprésent. Il n'y a pas d'ambiguïté. Quant au partage, je ne suis pas d'accord, cela dépend du taux de changement et de la quantité de changement qui va avoir lieu. DDD a le noyau partagé ... pour permettre au modèle d'être partagé entre les contextes ... et même si je devais dupliquer du code, le problème inhérent de corriger un bogue dans le code et d'affecter tous les services est toujours présent ... alors m'amène au contexte d'échange? .. c'est peut-être ce dont j'ai besoin ...
Microservices est un style architectural pas un cadre où nous choisissons peu de principes et en laissons quelques-uns en fonction des avantages et des inconvénients, il existe un autre style d'architecture appelé mini service qui vous donne la flaxiblité ce que vous aimez tout ce que vous pouvez utiliser (trouver dans le lien github que j'ai partagé), vous toujours libre de décider du style que vous voulez, même de nombreux avantages disponibles sur les anciennes applications monolithiques, spl lorsque vous déployez sur le cloud et le trafic d'entrée et de sortie et le coût de calcul du déploiement puisque vous et moi ne définissons pas l'architecture, nous devons suivre la même règle que la grammaire anglaise ou grammaire chinoise
Peu de composants tels que la sécurité ou la gestion des exceptions ou le code Spring jars à l'exécution, je peux comprendre si vous envisagez de créer une dépendance au moment de la compilation à l'aide du module maven, mais la logique métier et le domaine ne sont pas acceptables à partager en tant que bibliothèque de partage.
Vous aurez presque toujours des composants communs entre différents services.
Dans votre exemple, il semble que la bibliothèque partagée ne soit qu'un moyen courant pour le service A et le service B de communiquer avec le service C. Ceci est très similaire à avoir un code commun pour gérer un protocole de communication
Les services de découplage sont souhaitables pour de nombreuses raisons et doivent être recherchés dans la mesure du possible. Mais lorsque cela n'est pas pratique, il appartient au (x) développeur (s) de décider d'un plan d'action. Comme d'autres personnes l'ont souligné, vous pouvez envisager de reconcevoir votre système afin que ces dépendances courantes soient supprimées. Mais comme je ne connais pas le contexte et que cela a déjà été assez bien expliqué par d'autres, je vais en rester là et me concentrer sur le reste de la question
Si vous avez besoin de partager du code entre des services et que les services sont écrits dans la même langue, je le ferais avec une seule bibliothèque. Oui, vous devrez déployer la bibliothèque sur tous les serveurs pour toute modification. Mais au moins, les changements ne se produiront qu'à un seul endroit.
Personnellement, je ne vois aucun avantage à diviser cela en différentes bibliothèques. C'est déroutant - Vous devrez vous souvenir de vos différentes implémentations. Si les deux se cassent, vous avez deux corrections à apporter. Si quelque chose change, vous avez deux endroits pour effectuer le changement.
À quel point deux implémentations seraient-elles réellement découplées? ils font tous les deux la même chose , les deux dépendent des mêmes données et sont susceptibles d'être conçus par la même personne avec le même compréhension du problème. S'il y a des bogues dans l'un, il y aura probablement des bogues similaires dans l'autre.
La bonne réponse est toujours: cela dépend du contexte.
C'est ce que je pensais, il n'y a pas de solution miracle, tout dépend du rythme du changement et du contexte.