Normalização de banco de dados x dependências

Estou desenvolvendo 3-4 programas interdependentes. Chame-os de foo bar baz e auth. Eu quero que eles sejam independentes um do outro. Imagine se eu fosse licenciar cada programa para outras empresas. Algumas empresas podem querer fazer barulho, outras podem querer baz, etc. Também parece uma boa prática manter a autenticação independente também.

Contexto: auth está cuidando da autenticação para todos os sistemas. A tabela de usuários principais em auth possui user_id, email, senha, primeiro, último

foo também possui uma tabela de usuários que possui campos específicos para o aplicativo: user_id, role_id, etc.

Cada sistema possui seu próprio banco de dados. No passado, eu criei uma chave estrangeira de cada aplicativo para o auth db. Eu removi as permissões de atualização dos outros dbs, mas concedeu acesso de seleção a determinados campos relevantes. Isso parece uma solução ruim porque cria uma dependência estreita, mas me permitiu normalizar o banco de dados para que eu não tivesse que armazenar o nome e o email dos usuários nos bancos de dados foo, bar ou baz.

Seria melhor armazenar as informações em todos os bancos de dados? Ou seria melhor armazenar o ID de autenticação em foo bar e baz e usar uma API para obter as informações do usuário usando o authId?

Da mesma forma, eu posso ter clientes em todos os três sistemas. Claro que parece ruim criar uma dependência em um db de autenticação, mas e os dbs do cliente em todos os três?

Ou é a melhor solução para ter um banco de dados central. Uma tabela de usuários.

Outras sugestões?

Se você tem 4 serviços independentes, eles precisam ser independentes. Nenhum dado deve ser compartilhado em bancos de dados comuns ou similares, pois você simplesmente os torna dependentes!

Agora, embora seja correto compartilhar um único banco de dados em produção, os serviços devem usar seus próprios esquemas, pois o banco de dados existe apenas como um contêiner comum, semelhante à maneira como um único servidor Linux pode executar todos os 4 serviços.

Cada serviço deve ter sua própria API e essa é a única maneira de obter e receber dados de cada um. Portanto, seu serviço de autenticação armazenará usuários e executará autenticação, mas retornará algum token para identificar um usuário. Esse token é o que os outros serviços usam para lembrar qual usuário é qual - mas, caso contrário, eles não devem ter nenhum conhecimento de autenticação do usuário.

A maneira mais fácil de pensar em implementá-las é pensar no que você faria se decidisse usar um serviço de terceiros em vez dos que está escrevendo - se você usasse o serviço OpenID do StackExchange para usuários em vez do seu. Se você puder substituí-lo em sua arquitetura, terá um bom design independente.

Seu exemplo é um pouco abstrato, mas deixe-me passar por meus pensamentos.

Opção A: Na minha experiência, isso é sempre ruim, independentemente de seus motivos. Certifique-se de que bancos de dados como o MSSQL possam ter bancos de dados de amigos etc., mas se os dados estiverem vinculados, eles deverão estar no mesmo banco de dados

Opção B: Não tem certeza do que está acontecendo aqui, você está adicionando uma API que consulta todos os bancos de dados e reúne os resultados? Isso é melhor, mas se você tem aplicativos no topo dessa API, faz parte da camada de dados para eles e eles realmente usam apenas um dos bancos de dados. Por que eles colocaram os outros na camada de dados?

Opção C: Bem, isso funciona, mas não é bom ter um grande banco de dados com dados não relacionados. Você quer que os programas sejam independentes um do outro, certo? isso não ajuda nisso.

Opção D

Minha sugestão é abstrair a autenticação fora do conceito de userId. seu aplicativo de autenticação deve se preocupar com usuários e funções (ou promessas, etc., se você estiver modernizando) esses dados devem existir no banco de dados de autenticação

Cada aplicativo precisa ter um ID de usuário para agrupar dados por usuário, com alguns dados relacionados para fazer a chamada de autenticação e identificar o usuário para humanos. seria userId (exclusivo para o aplicativo), nome real, authusername, serviço de autenticação a ser usado. Esses dados devem existir no banco de dados do aplicativo

Os bancos de dados não devem ter conexão entre eles; conceitualmente, você poderá usar o facebook como seu serviço de autenticação, em vez de seu aplicativo de autenticação

Você pode precisar de informações adicionais para vincular um usuário se desejar relacionar um usuário foo a um usuário de barra

Eu recomendaria implementar o Logon único (SSO), por exemplo, com LDAP. Seus clientes maiores provavelmente também teriam se beneficiado com isso, pois poderiam substituir o aplicativo de autenticação interno por um banco de dados de usuário existente. Para seus clientes menores que não oferecem suporte ao SSO, você pode simplificar a implantação enviando seu aplicativo com um aplicativo de autenticação padrão.