Modèles de domaine partagé d'architecture de microservices

Supposons que nous avons une application Spring Boot qui utilise une architecture de microservices. Chacun des services a ses propres modèles de domaine, mais chaque service doit référencer un objet de domaine utilisateur. Quelle serait la meilleure approche pour résoudre ce problème? Serait-il préférable que chaque service ait simplement un ID utilisateur et, le cas échéant, demande au service utilisateur les détails de l'utilisateur, ou serait-il préférable d'avoir une bibliothèque de domaine partagée pour tous les microservices?

Si vous avez opté pour des microservices pour bénéficier de l'évolutivité, du couplage lâche et de la modification indépendante facile de chaque service, vous devez vous y tenir le plus possible.

Architecture globale

Je pense que la meilleure approche serait:

• disposer d'un microservice pour la gestion générale des informations utilisateur;
• conserver les informations utilisateur spécifiques au microservice (par exemple, profils, autorisations, préférences) dans chaque microservice (en utilisant le referene de l'id général)

Lecture supplémentaire:

• Cet article décrit très bien ce type d'architecture et de logique, avec le cas spécifique des autorisations.
• Cet article décrit les défis et la solution pour la gestion de l'identité des utilisateurs, afin d'éviter tous les services d'accéder au même référentiel.
• Cet article décrit comment utiliser JWT pour transmettre l'identité de l'utilisateur entre les services (en notant que certaines informations de base peuvent être fournies dans le jeton d'identification, ce qui évite d'avoir à interroger le service utilisateur une fois de plus après la connexion, du moins pour les informations de base) information).

Partage de Code

Maintenant, si vous êtes d'accord sur la solution ci-dessus, nous avons un microservice utilisateur (encapsulant le modèle de domaine pour l'utilisateur) et tous les autres services sont consommateurs du même microservice. La question est alors de savoir si vous voulez:

• soit chaque microservice pour réinventer le code de la consommation, suivant le dogme de la séparation forte pour permettre des cycles de libération souples et distincts,
• ou de partager le code consommateur dans le cadre de la bibliothèque, sachant que cette information fondamentale est une extension du modèle d'infrastructure "châssis" .

Je ne prendrai pas de position claire à ce sujet, car il existe des guerres d'opinion sur ce sujet de partage de code, et je ne pense pas que je suis en mesure de prendre une position objective. Voici déjà quelques lectures supplémentaires:

• Cet article pense qu'il n'y a pas de meilleure solution, et tout dépend de vos objectifs
• La position de cet article est que le partage de code n'est mauvais que s'il crée un couplage solide, et le partage de code peut apporter des synergies
• Cet article (des personnes qui ont implémenté des microservices à grande échelle) insiste sur la nécessité d'avoir des builds séparés et sur les problèmes potentiels de déclassement des anciens codes. Avoir une bibliothèque partagée pour consommer avec une gestion de version solide n'empêche pas ces bonnes pratiques.

Mon opinion personnelle à ce sujet est que vous NE DEVEZ PAS PARTAGER de code entre l'utilisateur-fournisseur et l'utilisateur-consommateur, afin d'éviter un couplage serré. Cependant, vous POUVEZ PARTAGER le code de consommation des utilisateurs entre les consommateurs si vous disposez d'une solide gestion des versions. Cette approche aurait certains avantages:

• Différents microservices consommant les utilisateurs pourraient être créés avec différentes versions du code de consommation partagée des utilisateurs (tant que les versions sont compatibles avec le fournisseur d'utilisateurs indépendant). Même flexibilité que réinventer la roue mais productivité plus élevée.
• Vous pouvez modifier votre service fournisseur d'utilisateur indépendamment sans impact sur les consommateurs.
• Si un bogue est détecté côté consommation, vous pouvez le corriger une fois et déployer tous les consommateurs au mieux (grâce à la gestion des versions). Cela pourrait même conduire à une meilleure qualité de service.
• Si, pour une raison quelconque, vous êtes obligé de mettre à jour l'API du fournisseur d'utilisateurs, vous pouvez déployer la consommation utilisateur mise à jour plus rapidement. Si vous maintenez l'ancien et le nouveau service fournisseur actif pendant la transition, cette possibilité de partage pourrait permettre de mettre hors service plus rapidement l'ancienne version du fournisseur fournisseur.

J'éviterais une bibliothèque partagée si possible. Demandez-vous de quelles propriétés d'un utilisateur chaque service a besoin? Souvent, il existe un domaine principal où la plupart des comportements entourant un utilisateur vivront, les domaines de prise en charge n'ayant souvent besoin que d'un ID utilisateur.

Si votre service a besoin d'autres détails concernant un utilisateur, consultez ici quelques suggestions sur la façon de gérer de telles situations