Les clés primaires de la base de données doivent-elles être utilisées pour identifier les entités dans les microservices?
Étant donné que j'ai deux microservices: le service A et le service B.
Le service A possède des données client complètes et le service B nécessite un petit sous-ensemble de ces données (qu'il obtient du service A par le biais d'un chargement en masse, par exemple).
Les deux services stockent les clients dans leur propre base de données.
Si le service B a alors besoin d'interagir avec le service A, disons pour obtenir des données supplémentaires (par exemple GET / clients / {id}), il a clairement besoin d'un identifiant unique qui est partagé entre les deux services.
Étant donné que les identifiants sont des GUID, je pourrais simplement utiliser le PK du service A lors de la création de l'enregistrement dans le service B. Ainsi, les deux PK correspondent.
Cependant, cela semble extrêmement fragile. Une option consiste à stocker l'ID externe (ou l'ID source) dans un champ distinct dans le service B et à l'utiliser pour interagir avec le service A. Et il s'agit probablement d'une chaîne car un jour, ce ne sera peut-être pas un GUID.
Existe-t-il une «meilleure pratique» à ce sujet?
mettre à jour
J'ai donc fait quelques recherches supplémentaires et trouvé quelques discussions connexes:
Devez-vous exposer une clé primaire dans les URL d'API REST?
Est-ce une mauvaise pratique d'exposer l'ID de base de données au client dans votre API REST?
Slugs comme clés primaires
conclusion
Je pense que mon idée d'essayer de garder les deux clés primaires pour le client de la même manière dans les services A et B était tout simplement fausse. Ceci est dû au fait:
- Il est clair que les PK sont spécifiques à l'implémentation du service, ils peuvent donc être totalement incompatibles, par exemple UUID vs INT auto-incrémenté.
- Même si vous pouvez garantir la compatibilité, bien que les deux entités soient toutes deux appelées «Client», il s'agit en fait de deux concepts (potentiellement très différents) et le Service A et le Service B «possèdent» tous deux leur propre enregistrement «Client». Cependant, vous souhaiterez peut -être synchroniser certaines données client entre ces services.
Je pense donc maintenant que l'un ou l'autre service peut exposer les données client via son propre identifiant unique (dans mon cas, le PK GUID) et si un service a besoin d'obtenir des données client supplémentaires d'un autre service, il doit stocker l'autre identifiant / clé de service et l'utilise. Revenons donc essentiellement à mon idée d '«identifiant externe» ou d' «id source» mais peut-être plus spécifique en tant que «id de service B».
Réponses
Je pense que cela dépend un peu de la source de données et de votre conception. Mais, une chose que j'éviterais de partager est une clé primaire qui est un GUID ou un entier auto-incrémenté vers un service externe. Ce sont des détails internes de votre service et non pas de quoi les autres services devraient dépendre.
Je préférerais avoir un identifiant externe qui soit mieux compris par d'autres services et peut-être par l'entreprise dans son ensemble. Il peut s'agir d'un numéro de client unique, d'un numéro de commande ou d'un numéro de police par opposition à un id. Vous pouvez également les considérer comme un "identifiant d'entreprise". Une chose à garder à l'esprit est qu'un identifiant externe peut également être exposé à un utilisateur final. Par conséquent, il s'agit d'une manière omniprésente d'identifier cette «entité» dans l'ensemble de l'organisation et des services, que vous ayez une conception événementielle ou que vos services parlent via des API. Je n'exposerais que les identifiants de base de données à l'infrastructure ou au référentiel. Au-delà, il ne s'agit que d'un identifiant professionnel / externe.
Eh bien, si vous avez une idée sur un objet de valeur, un identifiant d'entreprise sera beaucoup mieux pour la conception.
DDD se concentre sur les affaires, un ID d'incrémentation UUID / automatique pur ne peut pas le présenter.
Utilisez un identifiant commercial (identifiant UL), comme un identifiant client, au lieu d'un simple identifiant.