O JUST DRIVE foi construído do zero como um serviço coexistente. Na realidade não foi um equivalente exato do atual; em vez disso, foram introduzidas novas interfaces de usuário, adicionadas novas funcionalidades e realizadas mudanças significativas na estrutura de dados. O contexto delimitado do novo serviço é composto de seu modelo de domínio responsável pela lógica de negócios, o serviço de aplicação orquestrando casos de uso e gerenciando transações, e seus adaptadores de entrada e saída, como terminais REST e adaptadores para gerenciamento de persistência. O novo serviço domina o estado do documento exclusivamente - esse é o único serviço que pode ler e gravar documentos.
Como mencionado anteriormente, cada documento é criado por um autor, e os dados do autor são provenientes dos dados do perfil, os quais são gerenciados pelo monolito.
Para evitar a solicitação dos dados do autor a partir do serviço de perfil toda vez que o documento é exibido, foi mantida no novo serviço, uma cópia local dos dados relevantes de autor. A redundância de dados está correta desde que a propriedade dos dados não seja prejudicada - contanto que o contexto delimitado relacionado ao perfil ainda possua o estado do perfil com exclusividade.
Como a cópia local e os dados originais podem divergir ao longo do tempo, o monolito precisa notificar o novo serviço sempre que um perfil for atualizado. O monolito publica um ProfileUpdatedEvent assim que um perfil é modificado e o novo serviço é assinado. O novo serviço consome esse evento e atualiza sua cópia local.
Esta interação de serviço orientada a eventos aumentou o desacoplamento entre os serviços, uma vez que não era mais necessário realizar uma consulta remota de contexto diretamente ao monolito. Isto aumentou a autonomia, já que o novo serviço poderia fazer as alterações necessárias em sua cópia local e poderia tratá-los com mais eficiência, unindo os dados do autor localmente por sua cópia local, ao invés da rede.
O ponto de partida foi a criação de um serviço coexistente do zero, e foi introduzido a interação de serviço orientado a eventos para fins de duplicação de dados.
Criar um serviço coexistente a partir do zero é, em geral, uma boa estratégia de decomposição, especialmente para se afastar de algo, como, por exemplo, se livrar da lógica de negócios obsoleta ou da tecnologia. Porém, ao decompor o primeiro serviço, a equipe se deparou com muitos passos ao mesmo tempo. Como descrito anteriormente, não apenas foi criado um novo serviço coexistente, mas também foi introduzida uma nova interface de usuário, adicionadas mais funcionalidade e realizadas mudanças significativas na estrutura de dados. Devido à grande quantidade de mudanças logo no início, os resultados foram atingidos muito tardiamente. Em particular no começo, é muito importante recuperar resultados rapidamente para obter experiências antecipadas e confiança com microservices.
Com o próximo candidato, foi utilizada uma abordagem diferente. O foco foi concentrado no contexto delimitado de alto nível do aplicativo de bate-papo e na estratégia de decomposição incremental de cima para baixo, através da extração do código existente, passo a passo. Primeiramente, a interface do usuário foi extraída como uma aplicação web separada e foi introduzida uma API REST no lado do monolito, no qual a aplicação web extraída poderia acessar. Nesta etapa, seria possível desenvolver e implantar a aplicação web de forma independente, o que permitiu realizar uma iteração rápida na interface do usuário.
Após extrair a interface do usuário, foi possível prosseguir e decompor a lógica de negócios. Desembaraçar a lógica de negócios cria mudanças significativas no código. De acordo com as dependências, talvez seja necessário fornecer uma API REST temporária que o monolito utiliza para endereçar a lógica de negócios extraída. Neste estágio, o armazenamento de dados ainda era compartilhado.
Para se tornar um serviço desacoplado, o armazenamento de dados precisa ser dividido para garantir que o novo serviço possua o estado do bate-papo com exclusividade.
Em cada bate-papo de discussão, os participantes estão envolvidos. Os dados do participante do bate-papo derivam dos dados do perfil que residem no monolito. Conforme descrito no exemplo anterior do DRIVE, uma cópia local é mantida para os dados do participante do bate-papo e o ProfileUpdatedEvent é assinado para manter essa cópia local em sincronia com os dados originais do monolito.