Sollten Datenbankprimärschlüssel verwendet werden, um Entitäten über Microservices hinweg zu identifizieren?
Vorausgesetzt, ich habe zwei Microservices: Service A und Service B.
Service A besitzt vollständige Kundendaten, und Service B benötigt eine kleine Teilmenge dieser Daten (die beispielsweise von Service A über eine Massenlast abgerufen werden).
Beide Dienste speichern Kunden in ihrer eigenen Datenbank.
Wenn Dienst B dann mit Dienst A interagieren muss, um zusätzliche Daten zu erhalten (z. B. GET / customers / {id}), benötigt er eindeutig eine eindeutige Kennung, die von den beiden Diensten gemeinsam genutzt wird.
Da es sich bei den IDs um GUIDs handelt, kann ich beim Erstellen des Datensatzes in Service B einfach die PK von Service A verwenden. Beide PKs stimmen also überein.
Dies klingt jedoch äußerst fragil. Eine Möglichkeit besteht darin, die 'externe ID' (oder 'Quell-ID') als separates Feld in Service B zu speichern und dieses für die Interaktion mit Service A zu verwenden. Und wahrscheinlich ist dies eine Zeichenfolge, da es sich eines Tages möglicherweise nicht um eine GUID handelt.
Gibt es eine "Best Practice" dafür?
aktualisieren
Also habe ich noch etwas recherchiert und ein paar verwandte Diskussionen gefunden:
Sollten Sie einen Primärschlüssel in REST-API-URLs verfügbar machen?
Ist es eine schlechte Praxis, die Datenbank-ID dem Client in Ihrer REST-API zur Verfügung zu stellen?
Schnecken als Primärschlüssel
Fazit
Ich denke, meine Idee, beide Primärschlüssel für den Kunden für Service A und B gleich zu halten, war einfach falsch. Das ist weil:
- Offensichtlich sind PKs Service-Implementierungs-spezifisch, so dass sie möglicherweise vollständig inkompatibel sind, z. B. UUID oder automatisch inkrementierte INT.
- Selbst wenn Sie die Kompatibilität garantieren können, obwohl beide Entitäten zufällig als "Kunde" bezeichnet werden, handelt es sich tatsächlich um zwei (möglicherweise sehr unterschiedliche) Konzepte, und sowohl Service A als auch Service B "besitzen" ihren eigenen "Kunden" -Datensatz. Was Sie kann jedoch tun möchten , ist einige Kundendaten über diese Dienste synchronisieren.
Daher denke ich jetzt, dass jeder Dienst Kundendaten über seine eigene eindeutige ID (in meinem Fall die PK-GUID) verfügbar machen kann. Wenn ein Dienst zusätzliche Kundendaten von einem anderen Dienst erhalten muss, muss er die andere Dienstkennung / den anderen Dienstschlüssel speichern und diese verwenden. Also im Wesentlichen zurück zu meiner Idee 'externe ID' oder 'Quell-ID', aber vielleicht spezifischer als 'Service-B-ID'.
Antworten
Ich denke, es hängt ein bisschen von der Datenquelle und Ihrem Design ab. Eine Sache, die ich vermeiden würde, ist ein Primärschlüssel, der eine GUID oder eine Auto-Inkrement-Ganzzahl für einen externen Dienst ist. Dies sind interne Details Ihres Dienstes und nicht, von denen andere Dienste abhängig sein sollten.
Ich hätte lieber eine externe ID, die von anderen Diensten und vielleicht vom gesamten Unternehmen besser verstanden wird. Es kann sich um eine eindeutige Kundennummer, Bestellnummer oder eine Versicherungsnummer handeln, im Gegensatz zu einer id. Sie können sie auch als "Geschäfts-ID" betrachten. Beachten Sie auch, dass eine externe ID auch einem Endbenutzer zugänglich gemacht werden kann. Daher ist es eine allgegenwärtige Möglichkeit, diese "Entität" in der gesamten Organisation und den Diensten zu identifizieren, unabhängig davon, ob Sie über ein ereignisgesteuertes Design verfügen oder ob Ihre Dienste über APIs kommunizieren. Ich würde nur die DB-IDs für die Infrastruktur oder das Repository verfügbar machen. Darüber hinaus handelt es sich nur um eine geschäftliche / externe ID.
Wenn Sie eine Idee zu Value Object haben, eignet sich eine Geschäfts-ID viel besser zum Entwerfen.
DDD konzentriert sich auf das Geschäft, eine reine UUID / Auto-Inkrement-ID kann es nicht darstellen.
Verwenden Sie anstelle einer einfachen ID eine Geschäftsbedeutungs-ID (UL-ID) wie eine Kunden-ID.