Estilos arquiteturais são motivados por requisitos

Como definir um estilo arquitetural para um projeto com base nos requisitos

Definir uma arquitetura para um projeto, vai muito além de apenas adotar o modelo de arquitetura distribuída mais utilizado no momento. Na verdade, deveríamos nos preocupar no quanto estamos adotando soluções baseadas em microserviços ou baseado em eventos. Quanto mais distribuído e fragmentado, certamente teremos maior resiliência, capacidade de desacoplamento, vamos acelerar a entrega de novas atualizações, conseguiremos melhor proveito do hardware por unidade de negócio. Mas será que todas as soluções deveriam buscar esse "estado da arte"?

Pense no problema e na utilização

Ta certo que precisamos projetar soluções escaláveis, pensando no longo prazo, afinal, queremos crescer todas soluções que criamos. No entanto, algumas soluções, como por exemplo um sistema interno de registro de ponto em uma empresa de venda de bananas de 200 funcionários. É perfeitamente possível prever que esse sistema terá, na média, 200 acessos dia, dependendo das funcionalidades, 2,3 ou 4x o consumo. Ai vem algumas questões pra considerar:

  • Faz sentido explorar um estilo arquitetural de microserviços? Isso injetaria complexidade e a unidade de negócio desse sistema é extremamente pequena e não tem conexão com o core da empresa,  o que obviamente reduz muito as chances desse serviço ser consumido por algo além da própria aplicação de registro de ponto.
  • E utilizar uma arquitetura baseada em eventos? Bom, quero marcar meu ponto e no mesmo momento saber que foi registrado, se algo der errado, pensando no modelo de negócio e tamanho da empresa, um e-mail para o departamento de recursos humanos resolve o problema do ponto. Não precisa de uma capacidade de resiliência e recuperação a falhas (algo que provavelmente um sistema de uma aeronave precisaria ter como requisito principal).
Essas foram algumas provocações e a mensagem aqui é para lembrar que menos é mais, um monólito simples, ou até uma aplicação usando serverless no modelo (preferencialmente pay-as-you-go -não quero pagar por hardware quando ninguém estiver usando-), ou caso tenhamos um servidor físico, é perfeitamente aceitável manter nesse servidor físico, desde que consideremos a necessidade de manutenção (avaliar se a empresa suporta isso, seja via consultores ou efetivos). Enfim, bem resumido, a intenção é gerar a provocação e o questionamento sempre que pensarmos em arquitetura (menos é mais) e arquitetura, quanto mais distribuída, mais complexa de se manter.