Como Fazer…

Bom dia, pessoal.

Há cerca de 2 meses venho trabalhando em algumas ideias de aplicações, uma delas consiste em uma plataforma para ISPs e outra que ainda não posso detalhar. Tentei ao máximo seguir a regra com modelagem de dados ou conceitual, modelagem uml (classes, sequencia, componentes), modelagem dos processos. Em suma, isso é exatamente o que se costuma fazer. A maioria das pessoas que conheço que trabalham seriamente com desenvolvimento faz isso e julga isso suficiente para ter um produto de software aceitável. Isso tornaria o software suficientemente adequado a cobrir os requisitos apresentados no início do desenvolvimento, é um fato, mas, como todo mundo sabe, softwares são mutantes por natureza. Hoje começa ‘assim’, amanhã estará ‘assado’. Algumas mudanças são tão profundas que se torna complicado voltar aos diagramas e refazer. É um esforço ingrato.
Dessa forma, as modelagens acabam por se tornar obsoletas e pouco explicativas, não condizendo com o código, a estruturação ou ainda a documentação final do produto.
Como então resolver esse problema?
Bom, o problema começa no fato de não se definir claramente uma arquitetura logo no começo da aplicação, ou ainda, defini-la de maneira incompleta e não pensando de maneira escalável.
Vamos por partes:
Imagine uma aplicação que deverá ser utilizada por uma quantidade ilimitada de usuários, fornecer integração com outros sistemas e ser trabalhada na modalidade ‘freemium’, onde a aplicação seja de uso livre, mas com algumas funcionalidades disponíveis mediante pagamento.
Nesse cenário limitado, vejo a seguinte estrutura:

Vamos pular a etapa de modelagem e avançar para a escolha de itens como linguagem e plataforma de execução. O grupo de trabalho decidiu utilizar plataforma GNU/Linux para execução da aplicação e a linguagem para implementação escolhida foi PHP, utilizando algum Framework MVC com ORM.

Para a equipe isso significaria ‘escolha da arquitetura’, afinal MVC é uma arquitetura, não?

Errr… é complicado falar, mas está errado.

MVC é um ‘design pattern‘ ou padrão de projetos.

– Então, se isso está errado, como deveria ocorrer a escolha da arquitetura?

Vou tentar ser bastante claro, blz?

Escolhendo a arquitetura

Escolher a arquitetura exige, antes de mais nada, análise de requisitos. Uma análise correta de requisitos irá reduzir o desperdício de tempo tentando encontrar algum modelo arquitetural. De pronto, podemos identificar que a aplicação em questão exige a implementação de uma arquitetura n-tier (n-camadas).

– Ah, mas para implementar o MVC você já tem as múltiplas camadas presentes, tipo, camada visual, camada de abstração de dados e regras de negócios.

Ok! Correto. Mas não é apenas uma questão de camadas lógicas. Na escolha de arquitetura, você não deve pensar apenas em camadas lógicas. Devemos nos lembrar que teremos também as camadas físicas envolvidas no processo.

Por exemplo, no caso da integração com sistemas externos à aplicação, como os sistemas de pagamento ou outros sistemas quaisquer, você tem uma camada específica a estes.

Neste contexto, um dos padrões mais bem falados ultimamente é arquitetura em micro-serviços. Talvez você já tenha ouvido falar e talvez até já tenha vislumbrado utilizá-lo de alguma forma sem contudo entender como.

Alguns frameworks MVC para PHP, como Zend Framework, Symfony 3 ou o popular Laravel, suportam a criação e o provimento de Services. Esses services nada mais são do que classes que tem uma finalidade específica dentro da aplicação, ou como nos informa a documentação do framework Symfony: “a Service is any PHP object that performs some sort of ‘global’ task” .

Antes que você pare para pensar e perguntar, esse tipo de implementação não tem a ver com micro-serviços. No fim, aplicações desenvolvidas utilizando arquitetura MVC, mesmo que seja distribuída em módulos, acabam por se tornar monolíticas, difíceis de se trabalhar separadamente. Não discutamos isso agora. Para entender melhor a diferença, recomendo a leitura  deste post no blog da Caelum sobre arquitetura de micro-serviços.

Micro-serviços, APIs e JSON… SOA??

– Então, basicamente, devemos utilizar SOA?

Não estou dizendo isso.

Há muita discussão em torno do tema. Grandes nomes, bem maiores que o meu já formaram a base disso que estamos tentando entender. Dê uma lida neste artigo de Martin Fowler, nesta postagem na comunidade quora, para poder entender um pouco mais.

Só preciso dizer que algo foi herdado do padrão SOA, então, se temos alguma familiaridade com o esquema de troca de mensagens entre serviços, não será difícil implementar uma aplicação baseada em micro-serviços.

Vamos pegar a aplicação imaginada e dividi-la em micro-serviços?

Claro, o exemplo acima está ignorando alguns itens, como o ‘feature gateway’, mas serve para termos uma visualização de como funcionaria.

Pode-se notar que entre a aplicação e os micro-serviços ocorre a troca de mensagens, combinando assim com outro padrão, como por exemplo REST (REpresentational State Transfer). Daqui você pode entender que uma forma de implementar arquitetura de micro-serviços é fazendo uso de APIs. JSON é o formato preferido.

Para a aplicação de exemplo podemos ver a arquitetura de micro-serviços com a mais apropriada, porém há outras possibilidades. Poderíamos utilizar SOA ou criar uma aplicação monolítica.

A escolha da arquitetura deve respeitar, entre outras coisas, requisitos como escalabilidade, performance e facilidade de agregação da informação por ela utilizada.

Concluindo

Escolher a arquitetura de uma aplicação deve ser a tarefa primária do desenvolvimento,  e deve ocupar uma boa parte do tempo da equipe inteira, possibilitando a escolha do melhor modelo possível, evitando assim que no decorrer do projeto, surjam problemas que entravem todo o processo ou mesmo provoquem o insucesso da aplicação ao final.

Da próxima vez que surgir alguém perguntando qual o tipo de arquitetura de sua aplicação não vá logo falando: “Minha aplicação utiliza arquitetura MVC“.