Criando a Arquitetura do ARDA

ARDA foi nosso projeto interno de 2016. Gastei inúmeras horas discutindo a arquitetura e as tecnologias envolvidas, mas o aprendizado aconteceu somente quando mergulhei na codificação.

O código-fonte está aqui: https://github.com/dxbrazIl/arda

Antes de começar a analisar o código, é importante dar um pouco mais de contexto. Afinal, eu nem disse para que serve o Arda!

Objetivo

ARDA é uma ferramenta de gestão do time técnico com o objetivo de acompanhar a distribuição de tarefas entre os colaboradores.

Simplificando o produto, queríamos algo semelhante ao Trello e ao VSTS – começamos com a ideia de um Kanban. Era importante criar um Dashboard (Reports) com todas as métricas do nosso ano fiscal, então adicionamos as classificações de Categoria, Complexidade da tarefa, Métricas do scorecard e Fiscal Year. Por fim, queríamos ter segurança, então adicionamos o conceito de usuários e permissões.

Você deve pensar que é bem provável que essa ferramenta já exista no mercado ou que a própria Microsoft tenha uma também. Entretanto, nós somos técnicos. Nosso verdadeiro objetivo era aprender a fazer uma arquitetura baseada em Microservices e, portanto, seguimos em frente com nosso projeto.

Arquitetura baseada em Microserviços

Imagino que muitos projetos nascem exatamente da forma como fizemos:

• Existe uma necessidade de negócio: gestão de tarefa em um time técnico
• Há um viés por uma tecnologia: usar microserviços custe o que custar

Foi exatatamente isso que aconteceu no nosso time, resultando em diferentes visões de implementação.

Segundo algumas definições, microserviços são pequenos (micro) e autônomos. Por outro lado, a manutenção de serviços independentes gera complexidade desnecessária – veja o exemplo de tornar “Fiscal Year” como microserviço. Por que? Assim, seguiu nossa discussão:

• Fabricio Catae (eu) queria uma arquiteutra composta por 1 microserviço (Arda Core!!!)
• Fabricio Sanchez queria uma arquitetura composta por 10 microserviços (reports, kanban, workloads, backlogs, …)

Chamo isso de Problema do Fabricio^2. O tempo passa e nenhuma conclusão é feita para começar o projeto. Nem lembro o que as outras pessoas opinaram porque estava obcecado em MINHA arquitetura com 1 microserviço. Tenho certeza que o Sanchez estava concentrado somente em defender a ideia DELE. Enfim, a discussão era infinita e sem objetivo.

Solução do Problema do Fabricio^2

A solução para o impasse é fácil – basta adotar a estratégia de FAIL FAST: “Falhe. Mas falhe logo”.

No nosso caso, calculamos a média aritmética e chegamos a conclusão (muito empírico não?) de que precisávamos de 5~6 microserviços para resolver nosso problema. Fim de discussão sobre quem estava certo ou errado.

Logo que criamos os projetos no Visual Studio, começamos a nos dar conta de que seriam muitos e retiramos alguns deles. A discussão se tornou técnica.

No final, nossa arquitetura ficou da seguinte forma:

Isso significa que chegamos a um consenso e adotamos 4 microserviços. Isso resolveu o problema do Fabricio^2.

 

Conclusão

Cuidado com as discussões infinitas. Já cansei de ver Arquitetos de Solução defendendo a arquitetura ideal da aplicação com todo o racional baseado no Visio ou Powerpoint, mas sem sequer colocar a mão na massa e mostrar algo concreto. Infelizmente não acredito em nada disso. Uma boa arquitetura requer planejamento e parte desse plano precisa de uma prova de conceito.

Repetindo a frase com que comecei: gastei inúmeras horas discutindo a arquitetura e as tecnologias envolvidas, mas o aprendizado aconteceu somente quando mergulhei na codificação.

Logo, "menos PPT, mais código".

 

Referência

Vale a pena visitar os artigos do Fabricio Sanchez, que explica o projeto Arda e as considerações iniciais em detalhe. Essa é a versão bonita da nossa história de arquitetura:

https://fabriciosanchez.azurewebsites.net/3/arda-primeiros-passos-com-microservicos/

Recomendo que você faça uma leitura rápida para se familiarizar sobre o projeto. Nos próximos posts começaremos a detalhar o código e o banco de dados.