Modelo de domínio compartilhado entre diferentes microsserviços

Imagine um cenário de dois microsserviços diferentes. Um para lidar com a autenticação dentro do serviço, o outro cuida do Gerenciamento de usuários. Ambos têm o conceito de Usuário e falarão sobre Usuários através de chamadas entre si.

Onde o modelo de domínio de um "usuário" pertenceria embora? Ambos teriam uma representação diferente do que um Usuário está no nível do banco de dados? E quando tivermos um UserDTO para ser usado em chamadas de API, ambos terão um para suas respectivas APIs?

Qual é a solução geral aceita para esse tipo de problema de arquitetura?

Em uma arquitetura de microsserviços, cada um é absolutamente independente dos outros e deve ocultar os detalhes da implementação interna.

Se você compartilha o modelo, está acoplando microsserviços e perde uma das maiores vantagens em que cada equipe pode desenvolver seu microsserviço sem restrições e com a necessidade de saber como evoluir outros microsserviços. Lembre-se de que você pode usar idiomas diferentes em cada um deles, isso seria difícil se você começar a associar microsserviços.

Se eles estão muito relacionados, talvez sejam realmente como o @soru diz.

Perguntas relacionadas:

• Por que é tão ruim ler dados de um banco de dados "pertencente" a um microsserviço diferente
• Como você lida com conceitos compartilhados em uma arquitetura de microsserviço?

Se dois serviços estiverem suficientemente entrelaçados, seria difícil implementá-los sem compartilhar DTOs e outros objetos de modelo, isso é um forte sinal de que você não deve ter dois serviços.

Certamente o exemplo faz pouco sentido como dois serviços; é difícil imaginar uma especificação para 'Gerenciamento de usuários' tão complicada que manteria toda uma equipe tão ocupada que eles não têm tempo para fazer autenticação.

Se por algum motivo eles estivessem, eles se comunicariam usando o que são basicamente cadeias arbitrárias, como no OAuth 2.0 .

Você pode pensar neles como dois contextos limitados separados (na linguagem Design orientada a domínio). Eles não devem compartilhar nenhum dado entre eles, além de um ID usado para correlacionar o "Usuário" do contexto de Autenticação com o "Usuário" do outro contexto. Cada um deles pode ter sua própria representação do que é um "Usuário" e seu próprio modelo de domínio, que são apenas as informações necessárias para desempenhar sua responsabilidade comercial.

Lembre-se de que um modelo de domínio não tenta modelar uma "coisa" do mundo real, mas o que essa coisa está em um contexto específico (como Gerenciamento de identidade / autorização, Recursos humanos etc.).

Ambos têm o conceito de Usuário e falarão sobre Usuários através de chamadas entre si.

Também concordo com o que o @soru disse. Se um serviço precisar de dados de outro serviço, seus limites estarão incorretos.

Uma boa solução é a que o @pnschofield surgiu - tratando seus serviços como um contexto limitado.

Falando sobre o assunto, coloque em breve: modelos de domínio compartilhado matam a autonomia de serviço, transformando seu sistema de microsserviço em monólito distribuído. O que aparentemente é ainda pior que um monólito.

Portanto, ainda há uma questão geral não resolvida - como definir limites de serviço ou de contexto, para que eles prosperem com alta coesão e boa qualidade de acoplamento.

Eu vim com uma solução para tratar meus contextos como uma capacidade de negócios. É uma responsabilidade de negócios de nível superior, uma funcionalidade de negócios, contribuindo para o objetivo geral dos negócios. Você pode pensar nelas como as etapas que sua organização precisa seguir para obter valor comercial.

Minha sequência típica de etapas que tomo ao identificar os limites de serviço é a seguinte:

1. Identifique recursos de negócios de nível superior. Geralmente eles são semelhantes entre organizações do mesmo domínio. Você pode ter uma ideia de como é verificar o modelo da cadeia de valor de Porter .
2. Dentro de cada recurso, aprofunde e identifique sub-recursos.
3. Observe a comunicação entre os recursos. Veja o que uma organização faz. Geralmente, a comunicação é concentrada em recursos, notificando o restante sobre o resultado de seu trabalho. Portanto, ao implementar a arquitetura técnica, seu serviço também deve se comunicar por meio de eventos. Isso tem várias conseqüências positivas. Com essa abordagem, seus serviços são autônomos e coesos. Eles não precisam de comunicação síncrona e transações distribuídas.

Provavelmente, um exemplo dessa técnica seria de seu interesse. Não hesite em me informar o que você pensa, pois achei essa abordagem realmente lucrativa. Claro que pode funcionar para você também.

O microsserviço não se trata de "compartilhar nada", mas "compartilhar o mínimo possível". Na maioria dos casos, "Usuário" é uma entidade realmente comum (apenas porque o Usuário é identificado por algum identificador compartilhado - ID do usuário / email / telefone). Esse tipo de entidade compartilhada por definição. O modelo de usuário está fora do escopo de um microsserviço. Portanto, você deve ter algum esquema global, em que Usuário (apenas seus campos mais comuns) deve ser colocado. No caso estrito, é apenas identificação.