As chaves primárias do banco de dados devem ser usadas para identificar entidades em microsserviços?
Dado que tenho dois microsserviços: Serviço A e Serviço B.
O serviço A possui todos os dados do cliente e o serviço B requer um pequeno subconjunto desses dados (que ele obtém do serviço A por meio de algum carregamento em massa, digamos).
Ambos os serviços armazenam clientes em seu próprio banco de dados.
Se o serviço B precisar interagir com o serviço A, digamos, para obter dados adicionais (por exemplo, GET / clientes / {id}), ele claramente precisa de um identificador único que é compartilhado entre os dois serviços.
Como os IDs são GUIDs, eu poderia simplesmente usar o PK do Serviço A ao criar o registro no Serviço B. Portanto, os dois PKs correspondem.
No entanto, isso parece extremamente frágil. Uma opção é armazenar o 'ID externo' (ou 'ID de origem') como um campo separado no Serviço B e usá-lo para interagir com o Serviço A. E provavelmente esta é uma string, pois um dia pode não ser um GUID.
Existe uma 'prática recomendada' em torno disso?
atualizar
Então, fiz mais pesquisas e encontrei algumas discussões relacionadas:
Você deve expor uma chave primária em URLs de API REST?
É uma má prática expor o ID do banco de dados ao cliente em sua API REST?
Slugs como chaves primárias
conclusão
Acho que minha ideia de tentar manter as chaves primárias para o cliente iguais no serviço A e B estava simplesmente errada. Isto é porque:
- Claramente, os PKs são específicos da implementação do serviço, então eles podem ser totalmente incompatíveis, por exemplo, UUID vs INT auto-incrementado.
- Mesmo que você possa garantir a compatibilidade, embora as duas entidades sejam chamadas de 'Cliente', elas são efetivamente dois conceitos (potencialmente muito diferentes) e o Serviço A e o Serviço B 'possuem' seu próprio registro de 'Cliente'. O que você pode querer fazer, porém, é sincronizar alguns dados do cliente entre esses serviços.
Portanto, agora acho que qualquer serviço pode expor os dados do cliente por meio de seu próprio id exclusivo (no meu caso, o PK GUID) e se um serviço precisar obter dados adicionais do cliente de outro serviço, ele deve armazenar o outro identificador / chave de serviço e usá-lo. Então, essencialmente, de volta à minha ideia de 'ID externo' ou 'ID de origem', mas talvez mais específica como 'ID de B de serviço'.
Respostas
Acho que depende um pouco da fonte de dados e do seu design. Mas, uma coisa que eu evitaria compartilhar é uma chave primária que é um GUID ou inteiro de incremento automático para um serviço externo. Esses são detalhes internos do seu serviço e não dos quais outros serviços devem depender.
Prefiro ter um id externo que seja mais compreendido por outros serviços e talvez pela empresa como um todo. Pode ser um número de cliente exclusivo, número de pedido ou número de apólice, em vez de um id. Você também pode considerá-los como um "id comercial". Uma coisa a ter em mente é que uma id externa também pode ser exposta a um usuário final. Portanto, é uma maneira onipresente de identificar essa "entidade" em toda a organização e serviços, independentemente de você ter um projeto orientado a eventos ou se seus serviços se comunicam por meio de APIs. Gostaria apenas de expor os ids do banco de dados à infraestrutura ou repositório. Além disso, é apenas um id comercial / externo.
Bem, se você tem uma ideia sobre Value Object, uma ID de negócio será muito melhor para projetar.
O foco do DDD nos negócios, um UUID puro / ID de incremento automático não pode apresentá-lo.
Use um ID de significado comercial (UL ID), como um ID de cliente, em vez de um ID simples.