Modelo de domínio compartilhado entre diferentes microsserviços

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

Se você compartilhar o modelo, estará acoplando microsserviços e perderá uma das maiores vantagens em que cada equipe pode desenvolver seu microsserviço sem restrições e a necessidade de saber como evoluir outros microsserviços. Lembre-se que você pode até usar idiomas diferentes em cada um, isso seria difícil se você começar a juntar microservices.

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

Perguntas relacionadas:

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

Se dois serviços estiverem suficientemente interligados, seria difícil implementá-los sem compartilhar DTOs e outros objetos de modelo, isso é um sinal strong de que você não deveria 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 uma equipe inteira tão ocupada que não teria tempo para fazer autenticação.

Se, por algum motivo, eles estivessem, eles se comunicariam usando basicamente sequências arbitrárias, como em OAuth 2.0 .

Você pode pensar neles como dois contextos limitados (no jargão de design orientado 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 pode ter sua própria representação do que é um "Usuário" e seu próprio modelo de domínio, que apenas as informações necessárias para executar sua responsabilidade comercial.

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

They both have a concept of a User, and will talk about Users through calls to each other.

Eu também concordo com o que @soru disse. Se um serviço precisar de dados de outro serviço, seus limites estão errados.

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

Falando sobre o assunto, em breve: modelos de domínio compartilhados eliminam a autonomia do serviço, transformando seu sistema de microsserviço em monolito distribuído. O que é aparentemente pior do 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 em alta coesão e baixa qualidade de acoplamento.

Eu criei uma solução para tratar meus contextos como uma capacidade de negócios. É uma responsabilidade empresarial de nível superior, funcionalidade de negócios, contribuindo para o objetivo geral de negócios. Você pode pensar neles como etapas que sua organização precisa percorrer para obter valor de negócios.

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

1. Identifique os 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 do que parece verificar modelo de cadeia de valor de Porter .
2. Dentro de cada capacidade, aprofunde-se e identifique sub-capacidades.
3. Observe a comunicação entre os recursos. Veja o que uma organização faz. Normalmente, a comunicação é concentrada nas capacidades, notificando o restante sobre o resultado de seu trabalho. Portanto, ao implementar a arquitetura técnica, seu serviço também deve se comunicar via 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 desta técnica seria de algum interesse para você. Não hesite em me informar sobre o que você pensa, pois achei essa abordagem realmente lucrativa. Claro que pode funcionar para você também.