¿Deben usarse las claves principales de la base de datos para identificar entidades en los microservicios?
Dado que tengo dos microservicios: Servicio A y Servicio B.
El servicio A posee todos los datos del cliente y el servicio B requiere un pequeño subconjunto de estos datos (que obtiene del servicio A a través de una carga masiva, por ejemplo).
Ambos servicios almacenan clientes en su propia base de datos.
Si el servicio B necesita interactuar con el servicio A, digamos para obtener datos adicionales (por ejemplo, GET / customers / {id}), claramente necesita un identificador único que se comparte entre los dos servicios.
Debido a que los ID son GUID, simplemente podría usar el PK del Servicio A al crear el registro en el Servicio B. Entonces, ambos PK coinciden.
Sin embargo, esto suena extremadamente frágil. Una opción es almacenar el 'ID externo' (o 'ID de origen') como un campo separado en el Servicio B, y usarlo para interactuar con el Servicio A. Y probablemente esta sea una cadena, ya que un día puede que no sea un GUID.
¿Existe una 'mejor práctica' en torno a esto?
actualizar
Así que investigué un poco más y encontré algunas discusiones relacionadas:
¿Debería exponer una clave principal en las URL de la API REST?
¿Es una mala práctica exponer el ID de la base de datos al cliente en su API REST?
Babosas como claves primarias
conclusión
Creo que mi idea de tratar de mantener iguales las dos claves primarias para el cliente en los servicios A y B fue simplemente incorrecta. Esto es porque:
- Claramente, las PK son específicas de la implementación del servicio, por lo que pueden ser totalmente incompatibles, por ejemplo, UUID frente a INT autoincrementado.
- Incluso si puede garantizar la compatibilidad, aunque las dos entidades se denominan 'Cliente', son efectivamente dos conceptos (potencialmente muy diferentes) y tanto el Servicio A como el Servicio B 'poseen' su propio registro de 'Cliente'. Sin embargo, es posible que desee sincronizar algunos datos del Cliente en esos servicios.
Entonces, ahora creo que cualquiera de los servicios puede exponer los datos del cliente a través de su propia identificación única (en mi caso, PK GUID) y si un servicio necesita obtener datos adicionales del cliente de otro servicio, debe almacenar el otro identificador / clave de servicio y usarlo. Básicamente, volvamos a mi idea de 'identificación externa' o 'identificación de fuente', pero quizás más específica como 'identificación de B de servicio'.
Respuestas
Creo que depende un poco de la fuente de datos y de su diseño. Pero, una cosa que evitaría compartir es una clave principal, que es un GUID o un número entero de incremento automático para un servicio externo. Esos son detalles internos de su servicio y no de qué otros servicios deberían depender.
Prefiero tener una identificación externa que sea más entendida por otros servicios y quizás por la empresa en su conjunto. Podría ser un número de cliente único, un número de pedido o un número de póliza en lugar de un id. También puede considerarlos como una "identificación comercial". Una cosa a tener en cuenta también es que una identificación externa también puede estar expuesta a un usuario final. Por lo tanto, es una forma ubicua de identificar esa "entidad" en toda la organización y los servicios, independientemente de si tiene un diseño basado en eventos o si sus servicios se comunican a través de API. Solo expondría los ID de la base de datos a la infraestructura o al repositorio. Más allá de eso, es solo una identificación comercial / externa.
Bueno, si tiene una idea sobre el objeto de valor, una identificación comercial será mucho mejor para diseñar.
El enfoque de DDD en los negocios, un UUID puro / ID de incremento automático no puede presentarlo.
Utilice un ID de significado comercial (ID de UL), como un ID de cliente, en lugar de un ID simple.