Il y a la réponse des consultants de la mise en garde "cela dépend". Tout le monde a une description différente de ce que sont les microservices, mais pour moi, il s'agit de petits services déployables indépendamment qui font bien une chose (je souscris généralement à l'expression définition des microsevices par les aviateurs ).
En fait, je n'ai pas de problème à ce que les microservices partagent le stockage (qu'il s'agisse de bases de données, de stockage blob, etc.) tant que les microservices font partie du même périmètre de "service". Ce que j'entends par limite de service est un regroupement logique de petits services qui collaborent tous pour atteindre un objectif ou une capacité commerciale. Pour moi, c'est ce regroupement logique qui forme le "service", vu de l'extérieur de l'équipe. Un service, le service utilisateur, est souvent composé de nombreux petits microservices.
Par exemple, vous pouvez avoir un service "Utilisateur" qui se compose d'un certain nombre de microservices. Un pour capturer les intérêts d'un site Web et les stocker dans une base de données, un autre utilisé par le site Web pour traiter les changements d'adresse, un autre pour exécuter un travail dans le temps et envoyer des événements à d'autres services du système.
Mais vous ne voudriez pas que le service de génération de documents (service de rapport ?) lise et écrive à partir de la base de données utilisateur. Dans ce cas (comme l'a dit Stavreva), la communication événementielle entre les services serait la meilleure solution.
Vous seul, avec votre connaissance du domaine d'activité, pouvez décider si deux microservices appartiennent à ce même service. Une astuce consiste à examiner la capacité opérationnelle à laquelle le microservice contribue.
