Dados são a parte mais difícil de manipular em uma arquitetura de microserviço

Um dos problemas mais difíceis ao criar e desenvolver microserviços para uma empresa concentra-se na parte de dados. Analisar o domínio do negócio usando Domain-Driven Design (DDD) e a razão sobre o que os dados representam ajudará a chegar a uma arquitetura de microserviço, sustenta Christian Posta, principal Arquiteto de Middleware na Red Hat, em uma de uma série de posts sobre implementações de microserviço.

Para Posta, a principal razão para a escolha de uma arquitetura de microserviço é que ela permite às equipes trabalhar em diferentes partes de um sistema a uma velocidade diferente e com um mínimo de interferência entre elas. Ao organizar as equipes dessa forma, a arquitetura de sistemas poderá evoluir no sentido de uma arquitetura de microserviço.

O problema, porém, é fazer com que essa autonomia entre as equipes realmente funcione. E isso está longe de ser algo trivial. Abandonar as transações e o banco de dados único normalmente usados em uma aplicação monolítica, e mudar para transações com uma base de dados para cada serviço pode ser desafiador, especialmente para as empresas tradicionais.


Posta observa que existe uma enorme diferença entre a forma como as empresas de internet e as empresas tradicionais implementam microserviços. Enquanto as empresas de internet usam microserviços principalmente para lidar com enormes problemas de volume e de escala, as empresas tradicionais lidam tanto com a complexidade do negócio como de escala. A complexidade entre exibir filmes e postar tweets é muito menor do que a encontrada em um sistema de créditos de seguros, por exemplo.

Ao implementar microserviços para um domínio empresarial razoavelmente complexo, precisamos encontrar os limites entre diferentes responsabilidades dentro desse domínio. Em cada um desses limites, criamos um modelo de domínio, projetando e representando essa responsabilidade. O modelo de dados para cada limite é então conduzido pelo modelo de domínio no mesmo limite. Usando o DDD podemos encontrar esses limites e criar um contexto limitado para cada um, com cada contexto se tornando então um microserviço.

Na experiência de Posta, os desenvolvedores tendem a implementar sistemas distribuídos assumindo um único banco de dados relacional, e procuram abstrair as realidades de redes não confiáveis. Muitas vezes o problema com os dados distribuídos é resolvido valendo-se do commit de duas fases em vários serviços. Ao invés disso, Posta acredita que temos de olhar para os limites transacionais dentro de cada contexto limitado e encontrar a menor unidade de atomicidade necessária para impor restrições de negócio e invariantes, nunca permitindo que uma transação se espalhe para outros contextos.

Há ainda a necessidade de um serviço para informar outros serviços sobre o que está acontecendo e, para isso, Posta recomenda o uso de eventos. Um serviço publica eventos sobre coisas que acontecem no seu domínio e outros serviços irão ler esses eventos, adaptar-se a seus próprios modelos e persistir sob quaisquer alterações.

Para uma descrição mais detalhada dessas idéias, Posta faz uma referência a uma série de posts de Vaughn Vernon descrevendo agregados, limites de transação e contextos limitados com uma mentalidade DDD. Uma série que você pode acessar por completo aqui.

Fonte: InfoQ

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.