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:
- 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 .
- Dentro de cada capacidade, aprofunde-se e identifique sub-capacidades.
- 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.