Microsserviços: Padrões de decomposição
Introdução
Como decompor uma aplicação em serviços? Julgo que atualmente temos 2 principais maneiras de realizar a decomposição de microsserviços, e iremos explicar as duas neste artigo.
Vamos utilizar como base a funcionalidade de venda de um produto em um e-commerce.
Event Storming
Muitas vezes temos dificuldade ao encontrar os limites entre domínios, subdomínios e bounded contexts.
O Event Storming é um workshop criado por Alberto Brandolini. Ele visa facilitar a visualização de subdomínios e bounded contexts, além de auxiliar no processo de estabelecimento da linguagem ubíqua.
Vamos considerar o seguinte fluxo, para aplicar esta técnica.
Primeiro levantamos todos os eventos que serão gerados neste fluxo.
Um evento é algo imutável, que aconteceu no passado. Ele parte de uma alteração de estado. Exemplo: No momento em que realizar a inclusão do pedido, temos um evento gerado, chamado ‘Pedido Realizado’.
Dado isso podemos estabelecer um design inicial desse fluxo nos componentes.
Definindo limites
Como visualizamos os limites de um contexto? O maior sinal, é a mudança da linguagem ubíqua.
Exemplo: Primeiro incluímos o Pedido, depois realizamos o Pagamento.
Na primeira parte da frase estamos falando da entidade Pedido, e como ela irá sofre uma alteração de estado, em seguida mudamos nosso contexto para falar de pagamento.
Decomposição por subdomínio
O que é um subdomínio? O DDD implica na decomposição de um domínio em vários subdomínios, assim conseguimos separar o que de fato gera valor e retorno financeiro para a companhia, e assim, estrategicamente podemos colocar nossos maiores esforços nessa parte do Domínio.
A partir da definição dos contextos delimitados no nosso fluxo, podemos encaixar cada habilidade em seu contexto, a partir da agregação/entidade que ela manipula.
Exemplo: Incluir pedido
Ao realizar a inclusão de uma pedido temos a alteração de estado na entidade Pedido, gerando um evento ‘Pedido Realizado’. O Contexto responsável por esse pedido é o Pedido Context, onde podemos ter uma API de Pedidos, que será responsável por essa habilidade.
Seguindo esse modelo, podemos decompor toda a solução em serviços.
Decomposição por capacidade de negócio
O que é uma capacidade de negócio? Uma capacidade de negócios é a capacidade de uma organização de atingir um resultado ou objetivo específico. É uma combinação de pessoas, processos e tecnologia que uma organização precisa para executar uma tarefa ou função. As capacidades de negócios são os alicerces da estratégia de uma organização e são essenciais para atingir seus objetivos.
O objetivo do nosso fluxo de exemplo é realizar a venda de um produto.
A partir no desenho do nosso fluxo, componentes e entidades, podemos rastrear varias capacidades, identificando qual ação gera um alteração de estado.
Exemplo: Incluir pedido
As ações que geram alterações de estado na entidade pedido, são a ‘Incluir Pedido’ e ‘Cancelar Pedido’. A partir disso podemos assimilar que precisamos de uma capacidade de ‘Gerenciamento de pedido’ ou ‘Order Management’.
Abaixo temos o resultado do fluxo completo, em que cada cor de círculo significa uma capacidade.
Conclusão
Como podem ver os resultado são similares, afinal estamos falando de padrões de decomposição, é natural termos um resultado parecido, pois o objetivo é o mesmo.
As duas estratégias são ótimas opções, para decidir, acredito que o melhor é levar em consideração seu conhecimento sobre o negócio, e sobre DDD(Domain-Driven Desing).