Modelos de domínio compartilhado da arquitetura de microsserviço

Vamos supor que temos um aplicativo Spring Boot que usa arquitetura de microsserviços. Cada um dos serviços possui seus próprios modelos de domínio, mas cada serviço deve fazer referência a um objeto de domínio do Usuário. Qual seria a melhor abordagem para resolver esse problema? Seria melhor para cada serviço ter apenas um ID do usuário e, quando necessário, solicitar detalhes do usuário ao serviço do usuário ou seria melhor ter uma biblioteca de domínio compartilhada para todos os microsserviços?

Se você escolheu os microsserviços para se beneficiar da escalabilidade, do acoplamento flexível e da fácil modificação independente de cada serviço, você deve cumpri-lo o máximo possível.

Arquitetura geral

Eu acho que a melhor abordagem seria:

• possuir um microsserviço para gerenciamento geral de informações do usuário;
• mantenha informações específicas do usuário do microsserviço (por exemplo, perfis, autorizações, preferências) em cada microsserviço (usando a referência do ID geral)

Leitura adicional:

• Este artigo descreve muito bem esse tipo de arquitetura e lógica, com o caso específico de autorizações.
• Este artigo descreve desafios e soluções para o gerenciamento de identidade do usuário, para evitar que todos os serviços acessem o mesmo repositório.
• Este artigo descreve como usar o JWT para transmitir a identidade do usuário entre os serviços (observando que algumas informações básicas podem ser fornecidas no token de identificação, o que evita a necessidade de consultar o serviço do usuário mais uma vez após o logon, pelo menos para itens muito básicos. em formação).

Compartilhamento de código

Agora, se você concordar com a solução acima, temos um microsserviço de usuário (encapsulando o modelo de domínio para o usuário) e todos os outros serviços são consumidores do mesmo microsserviço. A questão é saber se você deseja:

• cada microsserviço para reinventar o código do consumidor, seguindo o dogma da forte separação para permitir ciclos de liberação flexíveis e distintos,
• ou compartilhar o código do consumidor como parte da biblioteca, considerando que essas informações fundamentais são uma extensão do padrão de infraestrutura do "chassi" .

Não tomarei uma posição clara sobre isso, pois há guerras de opinião sobre este tópico de compartilhamento de código, e não acho que estou em posição de assumir uma posição objetiva. Aqui já está uma leitura adicional:

• Este artigo considera que não há melhor solução e tudo depende dos seus objetivos
• Esta posição do artigo é que o compartilhamento de código é ruim apenas se criar um forte acoplamento, e o compartilhamento de código pode trazer algumas sinergias
• Este artigo (das pessoas que implementaram microsserviços em escala) insiste na necessidade de criar compilações separadas e nos possíveis problemas de desativação do código antigo. Ter uma biblioteca compartilhada para consumir com gerenciamento de versão sólida não impede essas boas práticas.

Minha opinião é que você NÃO DEVE COMPARTILHAR código entre o provedor do usuário e o consumidor do usuário, a fim de evitar um acoplamento rígido. No entanto, você PODE COMPARTILHAR o código de consumo do usuário entre os consumidores, se você tiver um gerenciamento de versão forte. Essa abordagem teria algumas vantagens:

• Diferentes microsserviços que consomem o usuário podem ser criados com versões diferentes do código de consumo do usuário compartilhado (desde que as versões sejam compatíveis com o provedor de usuário independente). A mesma flexibilidade que reinventou a roda, mas maior produtividade.
• Você pode alterar o serviço de provedor de usuário de forma independente, sem afetar os consumidores.
• Se um erro for encontrado no lado do consumo, você poderá corrigi-lo uma vez e implantar todos os consumidores da forma mais adequada (graças ao gerenciamento de versões). Isso pode até levar a uma maior qualidade de serviço.
• Se, por algum motivo, você for obrigado a atualizar a API do provedor de usuários, poderá implantar o consumo de usuário atualizado de forma mais rápida. Se você mantiver o serviço antigo e o novo provedor ativo durante a transição, essa possibilidade de compartilhamento poderá permitir a desativação mais rápida da versão mais antiga do provedor consumidor.

Eu evitaria uma biblioteca compartilhada, se possível. Pergunte-se de que propriedades de um usuário cada serviço precisa? Geralmente, existe um domínio principal no qual a maioria do comportamento em torno de um usuário permanecerá, com domínios de suporte que geralmente precisam apenas de um userId.

Se o seu serviço precisar de mais alguns detalhes sobre um usuário, dê uma olhada em algumas sugestões aqui sobre como lidar com essas situações