Conciliando uso de camadas com microservices

Falar sobre as vantagens de usar microservices seria um pouco repetitivo! Se você ainda não as conhece o google irá lhe ajudar a encontrar ótimos materiais que lhe apresentarão elas. Mas para quem trabalha ou está iniciando com microservices já deve ter percebido que também existem desvantagens. O fato é que não existe arquitetura que possua apenas vantagens ou desvantagens.

E porque essa questão logo de início? A resposta é simples: Fragmentar o monólito em microservices nem sempre tem trazido os ganhos prometidos!

Após trabalhar algum tempo com microservices, acompanhar várias empresas nesse desafio e participar de eventos que tratam do assunto, tenho me deparado com a figura abaixo:

Sempre que vejo essa imagem me pergunto: Porque ao fragmentar, algumas coisas não melhoram?

A resposta para isso não é simples, não há apenas um motivo para as coisas não melhorarem, mas uma coisa é fato: Ao fragmentar geralmente não melhoramos nossa forma de produzir código!

E dentre vários temas destaco nesse artigo o uso de Camadas!

Um dos primeiros sinais que percebo com relação ao abandono desse tema é quando falamos em camadas e muitas pessoas logo lembram do MVC, e se não há uma “View” em um microservice, o conceito de camadas não precisa ser aplicado. Até faz sentido, porém a questão é que MVC na verdade é um Design Pattern, que propõe um modelo de uso de camadas. Mas arquitetura em camadas vai além do que apresenta o Pattern MVC, podemos ter soluções com camadas físicas e camadas lógicas, e nelas 2, 3 ou N camadas. A verdade que é usar camadas te dá uma forma de organizar melhor o código, de entender onde cada implementação deve ficar respeitando a responsabilidade de cada camada.

Nesse sentido microservices podem sim fazer uso de camadas, principalmente quando pensamos em camadas lógicas. Independentemente do tamanho do microservice podemos por exemplo ter camadas como:

Ao pensar nessa camadas é muito fácil logo vir a ideia de “ok, já uso isso, qual o problema então?”. A grande questão é geralmente ao implementar nosso código não respeitamos essas camadas e criamos código nos lugares errados e isso pode gerar reflexos bem negativos a médio e longo prazo.

Vamos a alguns exemplos com relação a violações de camadas que normalmente fazemos em nossos sistemas:

• Controllers: Quantas vezes você já fez ou viu código que faz validação de atributos, de estados de uma entidade ou outras lógicas de negócio dentro de controllers? Se a resposta é sim (e não fique envergonhado disso) esse é um sinal de que você possui um código no lugar errado, e nesse contexto não importa se o sistema é um monólito ou microservice, a dificuldade de evolução e manutenção do código vai existir igual. Controllers são para controlar entrada e saída de dados, no máximo ter lógica relacionada a autenticação, sessão ou outros detalhes relacionados ao protocolo utilizado.
• Serializers: Usar serializers é legal, desde que neles não existam lógica de negócio, campos derivados, tratamentos de informação, dentre outros. Serializers são apenas para fazer um de-para de um objeto em memória para o formato esperado que pode ser um Json, Xml, Protobuffer, etc.
• Services: Um service geralmente é a camada que irá agrupar as regras de negócio, muitas vezes há outros termos com essa mesma responsabilidade como BusinessObject, Interactors, dentre outros. O fato é que se essa camada deve ter apenas regra de negócio! Não deveríamos ter código relacionado a regras de persistência ou ainda tratamentos pra retornar para camada acima apenas alguns atributos. Um service além de ter as regras de negócio pode saber invocar uma camada como a de persistência, processar dados e expor um objeto com todos dados para a camada acima.
• Repository: Essa camada, que em muitos sistemas pode ganhar nomes como models, persistence, dentre outros é a camada que deveria apenas receber um objeto e saber persistir ele. Aqui excluísse então qualquer regra de negócio ou qualquer tratamento relacionado a camada de controllers. Ela deve pura e simplesmente receber um objeto e persisti-lo, ou recuperá-lo do local onde está persistido.

O Fato é que muitas vezes estamos quebrando nossos monólitos mas não estamos (re)escrevendo um código de maior qualidade aplicando por exemplo o uso de camadas, ou ainda uso de velhos princípios como SOLID, Design Patterns, etc. Com isso a simples ação de quebrar o monólito em vários pedaços acaba não trazendo o efeito esperado principalmente quando pensamos em evolução e manutenção de sistemas.

Duas frases que ajudam bastante a entender se nosso código está ficando bom ou ruim quando falamos de camadas são:

• Quantos arquivos, classes e métodos serão modificados?

Se você está precisando modificar muitas coisas para pequenos ajustes ou evoluções no sistema, isso é um sinal de que talvez vocês não esteja aplicando de forma correta o uso de camadas.

• Seria possível trocar uma camada de forma fácil?

Se você olhar para seu microservice e tentar trocar uma camada e não conseguir, isso é um sinal de que seu sistema não está bem estruturado a nível de camadas. Um bom sistema deveria permitir a troca de camadas como controllers ou persistência sem necessidade de reescrever toda a solução ou refazer regras de negócio. Inclusive os testes automatizados deveriam continuar funcionando considerando apenas o ajustes relacionados a troca da camadas.

Enfim, a intenção com esse artigo é exercitar sua mente com relação a que: SIM!, é possível usar camadas junto com microservices. Isso é um passo com relação a produzirmos melhores códigos e consequentemente chegarmos a algo mais parecido com a figura abaixo:

A caminhada para fragmentar um monólito não é simples, há outras questões até mais importante como DDD, arquitetura orientada a eventos, imutabilidade de dados, dentre outros. O fato é que produzir um código melhor está além da fragmentação do seu monólito. Escolha usar microservices pelos motivos adequados e não apenas com a justificativa de que o código irá melhorar, pois para melhorar seu código na verdade você precisa fazer no microservice aquilo que normalmente não fazíamos no monólito.

Esse tema foi apresentado no TDC SP 2019, caso queira ver os códigos de exemplos, só acessar os slides aqui.

Tem alguma dúvida ou sugestão com relação ao tema? Só comentar!!! É importante termos várias visões sobre temas como estes para que possamos sempre evoluir a qualidade de nosso código!