Programming on Marsby Andre Lucas
/
MicrosserviçosMonolitoStrangler FigArquitetura de SoftwareMigraçãoDDDBounded Context

Migração Monolito para Microsserviços: Estratégia Strangler Fig Passo a Passo

Esquece o big-bang rewrite. Uma migração testada na prática de monolito para microsserviços com strangler fig: bounded contexts primeiro, domain events depois, split da base de dados por último. Passos concretos, não teoria.

Andre Lucas

Programming on Mars by Andre Lucas

July 28, 2024

Sobre

Migração de Monolito para Microsserviços com Strangler Fig

Arquitetura de Transição

Arquitetura Monolítica não é novidade para ninguém. Esse estilo arquitetural talvez faça sentido para muitas organizações, principalmente para startups que querem lançar seus MVPs, por exemplo.

Diagrama Monolítico

No entanto, bons produtos têm o potencial de crescer e, consequentemente, sua organização precisa crescer com eles. Portanto, com o tempo fará sentido mudar a arquitetura

Empresas que têm:

  • Equipe pequena
  • Prova de conceito (POC)
  • Restrição financeira (pouco capital)

Monolito é uma boa escolha

Bounded Context para Aplicações Monolíticas

Começando a criar uma aplicação com arquitetura monolítica, uma coisa importante que você precisa saber é separar seus bounded contexts em módulos.

Esses módulos podem se tornar microserviços no futuro.

Diagrama de Bounded Context

Por exemplo, podemos ver duas equipes diferentes focando em sua área e trabalhando juntas

Diagrama de Módulos de Equipes

No entanto, a aplicação é uma única aplicação que pode se tornar microserviços no futuro.

Bounded Context pode permitir que as equipes trabalhem em paralelo, evitando conflitos em momentos de integração, e desafios futuros de migração para a arquitetura de microserviços, facilitando a migração deles.

Comunicação Entre Módulos

Use um Domain Event para capturar uma ocorrência de algo que aconteceu no domínio. Esta é uma ferramenta de modelagem extremamente poderosa.

Vaughn, Vernon. Implementing Domain-Driven Design (p. 285). Pearson Education. Kindle Edition.

A facilidade de ter módulos juntos na mesma aplicação torna a integração entre eles fácil.

Assim, basta instanciar algumas classes e é possível usar outros módulos.

Portanto, essa situação pode trazer acoplamento entre módulos. Para preparar a integração entre eles no futuro, é possível usar eventos entre módulos.

Diagrama de Fila de Módulos

Para fazer isso existem muitas formas:

  • Transactional Outbox
  • Domain Events

Desacoplando Banco de Dados

Mas podemos ver que os dados estão acoplados porque estão unidos no mesmo banco de dados. Para facilitar o gerenciamento, ou migrar para arquitetura de microserviços, por exemplo, podemos criar um monolito modular com um banco de dados decomposto baseado em Newman, Sam. Building Microservices capítulo 1

Diagrama de Desacoplamento de Banco de Dados

CI/CD

Então, cada módulo pode ser implementado independentemente, mas para fazer deploy deles, ainda é necessário fazer isso juntos. Veja a imagem abaixo

Diagrama de Monolito Modular

Conclusão

Este não é o único formato para implementar uma aplicação monolítica modular, e isso não é uma regra, mas minha perspectiva e uma sugestão.

Referências

  1. Newman, Sam. Building Microservices
  2. Vaughn, Vernon. Implementing Domain-Driven Design

Tags

MicrosserviçosMonolitoStrangler FigArquitetura de SoftwareMigraçãoDDDBounded Context
← Back to home