Como modelar microserviços corretamente? [PT-BR]

Este post foi totalmente inspirado no livro Building Microservices de Sam Newman.

Introdução

Escrevi um post inicialmente sobre quando não usar microserviços, agora chegamos em um novo momento. Caso realmente faça sentido usar microserviços, como proceder? Como definir o que realmente faz sentido ser um microserviço? Qual parte do sistema deve ser isolada e se será apenas um ou vários para definir um fluxo de negócio de forma eficiente?

Como modelar microservices corretamente?

Modelar microservices não é apenas dividir uma aplicação monolítica em partes menores. É preciso definir boas fronteiras, garantir independência e criar uma arquitetura que realmente traga benefícios. Aqui estão alguns princípios essenciais:

Como fazer uma boa fronteira?

Uma boa fronteira de microserviço evita vazamento de informações, reduz dependências e melhora a escalabilidade. Para isso:

• Esconder dados e informações: Cada microserviço deve expor apenas o necessário.
• Coesão: Serviços devem ter um propósito claro e bem definido.
• Acoplamento: Minimizar dependências entre serviços garante mais flexibilidade.
• Coesão e Acoplamento juntos: Um serviço bem coeso e com baixo acoplamento resulta em alta modularidade, permitindo maior escalabilidade e facilidade de manutenção.

Tipos de acoplamento

Existem diferentes formas de acoplamento que podem surgir ao modelar microservices:

• Domínio (Aceitável): O serviço depende dos conceitos do negócio, o que é natural e desejável.
• Pass-through (Menos Aceitável): O serviço apenas encaminha chamadas sem lógica significativa, o que pode indicar uma falha na modelagem.
• Common (Ruim): Compartilhamento de código ou dependências comuns, como duas aplicações usando o mesmo banco de dados, pode gerar forte acoplamento e dificultar mudanças. Por exemplo, se um serviço precisa alterar o esquema do banco, o outro pode ser impactado, prejudicando a independência.
• Content (Péssimo): Dependência de estrutura de dados interna de outro serviço, resultando em alto acoplamento e fragilidade na arquitetura.

DDD e Microservices

O Domain-Driven Design (DDD) é um guia essencial para definir boas fronteiras e tornar os microservices mais independentes. Alguns conceitos-chave:

• Linguagem Ubíqua: Um vocabulário comum entre times técnicos e de negócio, garantindo que todos compreendam os termos do domínio.
• Aggregate: Um aggregate deve agrupar entidades e objetos de valor que são tratados como uma única unidade, garantindo consistência interna. A definição de um aggregate deve seguir as seguintes regras:
  • As mudanças dentro do aggregate devem ser atômicas e consistentes.
  • O acesso externo a entidades internas do aggregate deve ser mediado pelo aggregate root.
  • Exemplo: Em um sistema de pedidos, o aggregate pode ser o Pedido, contendo itens, endereço de entrega e informações de pagamento. Qualquer alteração deve ser feita através do Pedido, garantindo integridade.
• Bounded Context: Define limites claros entre diferentes domínios de um sistema. Para modelar um bounded context corretamente:
  • Identifique os conceitos de negócio que pertencem ao mesmo contexto e separe-os daqueles que não têm relação direta.
  • Evite dependências entre bounded contexts distintos para evitar acoplamento indesejado.
  • Exemplo: Em um sistema de e-commerce, o contexto de "Pedidos" não deve depender do contexto de "Catálogo de Produtos", pois cada um possui regras específicas e independentes.

Por que DDD casa tão bem com microservices?

O DDD se encaixa perfeitamente com microservices porque:

• Permite dividir o sistema em contextos bem definidos, facilitando a identificação das fronteiras dos microservices.
• Reduz a complexidade ao encapsular lógica de negócio dentro de aggregates, garantindo consistência interna.
• Facilita a comunicação entre times por meio da Linguagem Ubíqua, evitando mal-entendidos.
• Ajuda a evitar acoplamento excessivo ao definir boundaries bem estabelecidas, permitindo que cada microservice evolua de forma independente.

Alternativas ao DDD

Embora DDD seja uma abordagem sólida, existem outras estratégias para modelar microservices:

• Volatilidade: Separar serviços considerando a frequência de mudanças, isolando partes mais voláteis para evitar impactos em outros serviços.
• Dados: Projetar microservices em torno da posse e acesso a dados, garantindo que cada serviço tenha seu próprio repositório.
• Tecnologia: Definir serviços de acordo com a stack tecnológica, permitindo o uso da melhor tecnologia para cada caso.
• Organização: Criar serviços alinhados com a estrutura das equipes (Conway’s Law), promovendo autonomia e agilidade.

Referências e Leituras Recomendadas

Para aprofundar seus conhecimentos sobre modelagem de microservices, recomendo as seguintes leituras:

• Building Microservices - Sam Newman: Livro essencial sobre a arquitetura de microservices, que deu origem a ideia desse post, cobrindo desde a modelagem até a implementação e manutenção.
• Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans: O livro original sobre DDD, explicando em profundidade os conceitos de agregados, bounded contexts e linguagem ubíqua.

Ao modelar microservices corretamente, evitamos armadilhas como dependências excessivas e serviços mal definidos, garantindo uma arquitetura escalável e sustentável. Como você tem modelado seus serviços?