Primeiro de tudo, eu começaria com a descrição do domínio. Você não mencionou sobre o que é (eu posso imaginar, mas seria apenas um palpite). Depois disso, tentaria decompô-lo usando análise de cadeia de valor ou mapeamento de capacidade comercial . E só depois disso eu pensaria em implementação.
Considerando o seu problema, a primeira coisa que me vem à mente é que você identificou seus limites de serviço errados, simplesmente porque eles precisam dos dados uns dos outros. Você não quer acabar com o monolito distribuído , né?
A segunda coisa é que você provavelmente não trabalhou bem no seu domínio. Qual conceito é representado com users
table? É um registered user
, com todas as informações e comportamentos necessários para o registro? Você tem certeza de que é o conceito certo para se comunicar com trackers
(seja o que for)? Então, se eu entendi direito, sua opção 2 é exatamente isso: introduzir o conceito owner
que é muito mais próximo do seu domínio. Se realmente é assim, eu sou para a opção 2 também.
However, it seems out of scope for microservice B. Why should microservice B care that microservice A wants to create an association?
É tudo sobre limites. Eu acho que você quer formar microservices em torno de entidades. É onde SOA falhou com seu Arquitetura de serviço de camadas . A melhor abordagem é criar serviços que representem alguma função de negócios, para que eles encapsulem os dados e o comportamento. Do ponto de vista mais prático, trata-se de criar serviços em torno de processos de negócios ou casos de uso. Por exemplo, você pode ter um serviço para o registro do usuário. Ele contém os dados e o comportamento do usuário necessários para registrar um usuário. Assim, o conceito de user
é formado naturalmente, e pertence apenas ao serviço A. E isso me leva ao próximo ponto: a outra maneira de pensar sobre os serviços é conectado vinculado . É uma boa prática alinhar serviços e contextos limitados.
Quando o usuário é registrado, o evento UserCreated
pode ser emitido. Seu segundo serviço, acho que está interessado nisso. Assim, ao recebê-lo, uma entidade completamente diferente poderia ser criada, digamos, Owner
entity (seja lá o que for, também). Tenho certeza de que existem muitas colaborações interessantes entre ele e tracker
entity - mantenha-as em um único serviço.
Seja extremamente cauteloso com a opção 3. Se você copiar dados, segue-se a funcionalidade. Isso resulta em acoplamento apertado. E não cubra com o termo CQRS , não se trata de sincronização de dados entre serviços via eventos.