O SOFTware nasceu quando a necessidade de criar e modificar as partes de um sistema se tornou maior, e precisava ser mais rápida do que seria possível alterar um HARDware. A ideia principal por trás do software é a capacidade de ser modificado com velocidade, é um dos principios do que chamamos hoje de “arquitetura de software”.
A arquitetura é toda a estrutura e organização do código, desde a separação desse código em componentes e suas classes, funções, quanto a comunicação entre esses componentes e entre outros softwares (como APIs, bancos de dados, etc.). Acredito que uma boa arquitetura é uma arquitetura preguiçosa, ou procrastinadora.
Uma arquitetura não é algo que se define e simplesmente aplica no desenvolvimento, como é, por exemplo, na escolha da linguagem de programação utilizada. Uma arquitetura é descoberta. Ela acompanha e atende as necessidades do modelo de software. Um ponto importante aqui é que, assim que uma arquitetura começa a ser descoberta, ela não será assim para sempre. Dentro de uma evolução constante no mundo e principalmente nos negócios, nossa aplicação evoluirá também, consequentemente nossa arquitetura, portanto, o modo correto muda constantemente.
Hoje em dia, é muito comum que iniciarmos escolhendo nosso framework, banco de dados, e com isso, acabamos por definir uma certa arquitetura, o problema é que muitas vezes essa “arquitetura” se torna rígida, e dificulta a evolução da própria arquitetura e consequentemente do software. Controlar essas dependências é essencial, e ai entra o conceito de “arquitetura procrastinadora”. Manter o máximo de decisões em aberto, e evitar tomar essas decisões até que seja realmente necessário, aumenta muito a utilidade da nossa arquitetura e nosso software.
Devemos utilizar microserviços ou monolito? Que tal um banco de dados NoSQL? Será que podemos utilizar CQRS? Essas e outras decisões, comumente são tomadas antes da hora e por motivos variados. Nossa arquitetura, para que seja útil, deve suprir alguns pontos, como a velocidade de mudança e manutenção, a capacidade de extensão, a facilidade de implantação e escalabilidade. Se nos comprometemos com outros recursos, utilizamos diversas ferramentas antes da hora, isso pode nos ferir quando chegar a hora de mudar.
Talvez o exemplo mais debatido hoje em dia seja o microserviço x monolitico. O monolítico foi o padrão da industria por muitos anos, e tem lá seus problemas. Com a crescente demanda das aplicações e necessidade de escalar à niveis que até parecem exagerados, os monoliticos começaram a falhar em entregar. Com isso, os microserviços se tornaram cada vez mais populares, e como toda ferramenta popular no nosso meio, começou a ser cada vez mais mal usada. Muitas vezes o problema dessas decisões foi só timing.
Esse é o ponto central deste artigo: timing. Uma boa arquitetura deve deixar o máximo de decisões não tomadas pelo máximo de tempo possível. As decisões devem ser tomadas apenas quando necessário, e ainda assim, é importante que essas decisões não ingessem o nosso software. É igualmente importante manter nosso software aberto para extensão mas fechado para mudanças é o desejável. Quanto mais decisões “em aberto” temos na nossa arquitetura, mais facil ela será de ser modificada, e quanto mais facil ela é de ser modificada, mais próximos estamos do SOFTware.
