Comment gérez-vous les concepts partagés dans une architecture de microservice?

Je suis à la recherche de modèles architecturaux pour une application que je développe et une approche de microservice semble être un bon choix, mais je ne sais pas comment gérer les interactions entre les services.

L'application traite principalement des utilisateurs, des profils appartenant à des utilisateurs, des photos et des balises représentant un à plusieurs profils d'une photo. Il serait concevable qu'il existe des méthodes pour renvoyer les photos téléchargées par un utilisateur, renvoyer des photos contenant un certain profil étiqueté, etc.

C’est la première fois que j’essaie de concevoir une architecture reposant sur un microservice. Je viens d’une histoire inspirée par les modèles monolithiques . Dans ce monde, les contrôleurs associent ces objets de domaine, mais j'ai du mal à comprendre comment cela fonctionnerait sous forme de microserveur.

Habituellement, les services appellent d'autres services lorsqu'ils ont besoin d'accéder à leurs données. Chaque donnée doit appartenir à un service particulier qui sera le seul point d’entrée pour accéder à ces données et les modifier. Certains services seront simples et correspondront généralement étroitement à votre modèle de domaine (par exemple, un service de gestion des utilisateurs), tandis que d'autres seront de haut niveau et utiliseront les données d'autres services (par exemple, afficher une liste de photos avec des informations sur les utilisateurs qui les ont téléchargées. ).

Dans votre cas d'utilisation, commencez par l'extérieur et réfléchissez aux opérations que vous souhaitez mettre à la disposition de votre utilisateur via une API (s'il s'agit d'un service backend) ou quelles opérations doivent être disponibles dans l'interface graphique s'il s'agit d'une application Web. Notez que la partie graphique est souvent une application régulière avec ses propres contrôleurs: les opérations peuvent être appelées via REST (comme dans AngularJS), mais ces noeuds finaux sont conçus uniquement pour l'utilisation de l'application graphique et ne constituent pas des microservices au sens commun.

Supposons que vous souhaitiez afficher des photos avec des informations sur les téléchargeurs. Vous pourriez avoir un service utilisateur qui renvoie des informations sur un utilisateur à partir de son identifiant et un service photo pouvant répertorier des photos (par exemple en effectuant une recherche selon certains critères). La liste des photos contiendrait pour chaque photo l'identifiant de l'utilisateur chargé du téléchargement. De cette façon, ces deux services ne sont pas couplés - le service photo ne connaît que les identifiants d’utilisateur, mais rien sur les données de l’utilisateur lui-même. En plus de ces deux services, vous pouvez créer un troisième service avec une opération telle que "liste des photos avec des informations sur les téléchargeurs", qui appelle les deux autres services et combine les données qu’ils renvoient. Cette opération peut également être effectuée par votre application Web au lieu d'un service.

L'application traite principalement des utilisateurs, des profils appartenant à des utilisateurs, des photos et des balises représentant un à plusieurs profils d'une photo. Il serait concevable qu'il existe des méthodes pour renvoyer les photos téléchargées par un utilisateur, renvoyer des photos contenant un certain profil étiqueté, etc.

Eh bien, le service de profil ne devrait pas fonctionner avec un objet utilisateur. Il peut ne connaître que l'ID de l'utilisateur pour lequel il est demandé de renvoyer des données, pas plus. De cette façon, vous n'aurez pas besoin d'interaction entre le service utilisateur et le service de profil.

Si cela ne répond pas à votre question, pourriez-vous clarifier la situation en décrivant la situation exacte à laquelle vous faites face?