🇧🇷 Princípios na modelagem de serviços

Imagine que você começa a desenvolver microserviços e a primeira dúvida surge: Qual funcionalidade eu quero desenvolver? Parece simples responder, mas não vá com tanta sede ao pote, pois nem sempre a primeira resposta é a solução.

Antes de colocar a mão na massa é necessário identificar propriedades, nomes, entidades e interações. Vou escrever aqui três princípios que tenho aplicado com sucesso antes de iniciar qualquer projeto.

Serviços são autônomos

Dado o significado, podemos aplicá-lo à modelagem de serviços, que devem ter autonomia suficiente para exercer sua capacidade de negócio sem depender de outros serviços.

Caso isso não seja obedecido, você verá serviços se tornando cliente de outros serviços e com isso, threads, memória e CPU estarão dependentes da capacidade de resposta de outros serviços.

Isso se torna caótico quando existe uma cascata de dependência: “Serviço A” depende do “Serviço B”, e “B” depende de “C”.

Serviços não compartilham classes/tipos

Quem nunca alterou o schema de um tipo de dado, achando que não existia dependência e eventualmente quebrou um outro código, que nem sabia de sua existência ? A situação só piora com o tempo, pois com as mudanças que ocorrem em um determinado negócio, perdemos o controle de dependências, que agora estão compartilhados e escondidos.

Em essência recursos compartilhados escondem alto acoplamento. Tenha cuidado!

Ao invés de compartilhar recursos com alto acoplamento, modele suas dependências explicitamente através de mensagens. Já tive a oportunidade de escrever sobre eventos anteriormente, mas outra forma comum de mensagens são comandos (usados para solicitar uma ação dentro dos limites do seu serviço).

Serviços não são donos de entidade

O fato é que serviços são donos de parte da entidade que fazem sentido para exercer a sua capacidade de negócio.

Vamos supor que você desenvolve um eCommerce de uma livraria e precisa modelar o processo de vendas, pagamento e entrega. Então você decide criar uma entidade que conterá os dados de Pedido: cliente, produtos, quantidades, valores, informações de pagamento e endereço de entrega.

Aparentemente tudo certo e funcional, mas agora nosso eCommerce cresceu e vamos passar a vender e-books. O que fazer com o endereço de entrega, que agora não terá sentido quando for uma venda de e-books? O endereço ficará nulo, dando sentido de que aquela venda se trata de um e-book ? 🤔

Acrescentando mais à nossa história, agora queremos expandir nossos meios de pagamento e vamos passar a aceitar bitcoins, que têm uma forma de pagamento completamente diferente dos meios convencionais. Vamos adicionar um atributo a mais para contemplar as necessidades do bitcoin e deixar os atributos de meios de pagamento nulos quando não fizerem sentido ? 🤔

Para as perguntas nos parágrafos acima, a solução é dividir o domínio da Venda entre partes onde cada um faça sentido para sua capacidade de negócio.

Quando necessário, o serviço de logística será acionado para exercer sua capacidade de entrega. Da mesma forma o serviço de Faturamento saberá determinar quando e de que forma cobrar um determinado valor relacionado a uma venda. Enquanto isso o serviço de venda se preocupa em fazer o relacionamento da venda com o cliente.

Tendo em mente esses três princípios, você irá notar que alterar a capacidade de seu negócio se tornará uma atividade rápida e facilmente testável, uma vez que toda a capacidade de negócio está embutida dentro de um serviço autônomo, desacoplado e coeso.

Este artigo também está disponível em inglês.

Software Engineer and passionate about distributed systems

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store