Quando se inicia no desenvolvimento de software, necessariamente não perdemos tempo focando no desenvolvimento de software à longo prazo. Afinal quem pensa em levar projetos de treinamento para a vida? (Deus me livre voltar a códigos que desenvolvi no início dos meus estudos). Porém quando engatinhamos para desenvolvimentos de projetos próprios, os freelas, ou entramos no tão sonhado estágio, podemos supor que todos os envolvidos esperam que os seu desenvolvimento seja ao menos capaz de se manter em pé por algum tempo. Para que isso ocorra, uma das principais armas que o desenvolvedor pode contar é arquitetura de software, a utilização de um "padrão” de desenvolvimento que se encaixe na solução que você quer prover através do seu código.
Antes de iniciar o desenvolvimento de um software é importante como desenvolvedor entender o que se é esperado daquela solução. Qual o seu tamanho inicial, se ela poderá crescer, como ela irá se comportar e se é possível que um dia ela mude de características básicas. Sabendo de tudo isso, teremos um perfil com algumas características para encaixar seu desenvolvimento em uma arquitetura.
Neste post irei te ajudar a conhecer algumas das arquiteturas mais conhecidas no mercado atual e falar um pouco sobre as suas características, exemplos de como utilizá-las e indicar mais leitura (sim, seu preguiçoso, mais leitura) sobre o tema. Assim você será capaz de definir que caminho você irá escolher (siga seu coração e continue errando).
obs: pode guardar para você a sua opinião sobre a utilização de tal padrão de projeto e a sua arrogância em achar que pode inventar um padrão sozinho, ou pior ainda, a sua opinião que se pode não utilizar uma arquitetura no projeto. Eu não ligo, e ainda vou te achar burrinho por isso.
O clássico, monólito.
Comecemos pelo terror de todos e o amor de nenhum, o querido, temido e se pá admirado Monólito. O monólito é uma arquitetura que centraliza todos as funções, serviços e aplicações dentro de um único local, executada com um único processo dentro de uma única plataforma. O problema disso deve ser claro, né? né? né…? Tá, imagina que você inicia uma aplicação que armazena apenas cds que os seus usuários possuem. Agora imagina que adicionamos dvd's na parada, e logo após blu-rays. Tudo bem, armazenagem é uma parada que podemos considerar como um único contexto. Mas agora imagina que além de armazenar, queremos que reproduzam essas mídias, que se faça uma legenda autogerada e um tratamento de imagem e controle de taxa de execuções das mídias visuais. Que sopa esse negócio vai virar se continuarmos a utilizar o mesmo monólitão? Nesse contexto é inviável utilizar um monólito para servir como base da sua aplicação. Por ser tornar um problema maior que a solução, o monólito tem sido descontinuado gradualmente de diversos big projetos, mas ele como todo clássico ainda tem o seu charme em ser simples e elegante para certas ocasiões. Tipo, você não quer perder tempo servindo um dashboard que somente faz cálculos matemáticos simples e mostra em uma tela. O vovô das arquiteturas não tem o melhor desempenho, mas ainda serve bem. Se pá a pipa sobe.
O responsável e não tão correto, Layered
Arquitetura Layered ou arquitetura em camadas nasceu com a proposta de dar um basta na suru.. digo, confusão que o monólito causava. O seu principal objetivo é organizar e separar diferentes contextos com responsabilidade. Seguindo o exemplo anterior, ao se ter um sistema que utilizasse as mídias, poderíamos ter um sistema de cds, sistema de dvds, sistema de blurays, e todos eles utilizariam um sisteminha de inserção de mídia, reutilizando o código entre si e possibilitando a manutenção mais rápida, por parte de apenas um sistema e não todo o sistema.
O modelo de camadas não é uma novidade na área da computação, visto que já dividimos a estrutura de redes em camadas de responsabilidade e o sistema operacional em camadas de aplicação, kernel, IO e etc. Novo mesmo para o desenvolvimento de software é a aplicação disso no contexto de código-fonte.
Pode parece sensato se dividir um sistema em camadas, e é em muitos os casos, mas a complexidade da solução está entre as distâncias que as camadas possuem. Imagina que naquele sisteminha hipopótamo que pensamos, além da inserção de cds no banco necessitemos de uma tradução de mídia, e um tratamento de áudio para deficientes auditivos. São 3 contextos diferentes para esse serviço, 3 camadas diferentes, 3 locais para se modificar caso exista uma correção ou remoção do serviço. A complexidade vai aumentando a cada camada que adicionamos ao bolo.
O dominante, Cliente-Servidor
Imagina que louco seria trabalhar na horizontal? algumas pessoas conseguem, outras só sonham. A arquitetura cliente-servidor vai trazer essa premissa. Centralizar serviços compartilhados em um único local, e servir quando necessário para os seus clientes. Que linda ideia não é? mas qual seria a diferença entre essa arquitetura e a de um monólito ou de Layered? Quais são os serviços escolhidos para estar no nível servidor e quais os serviços clientes. Depois do after party do senhor Layered, temos uma não-monogamia de serviços sendo prestados a qualquer um que peça (com respeito e sabendo conviver com limites). Sem camadas, aquele probleminha anterior é resolvido com apenas a separação da transcrição, tratamento de som para o servidor e o cliente, sendo a inserção da mídia, requeria as duas funcionalidades objetivas. Concorda que é uma boa ideia? é uma boa ideia, até certo ponto. Assumindo que queremos prover essas duas funcionalidade por um único ponto de entrada, teríamos que trabalhar com um único processo e o pior, gerenciar a possível concorrência de processo afinal, um servidor não terá apenas um cliente.
O cliente-servidor é um velho amigo que tem que controlar quantos rolês ele pode aceitar em um fim de semana. Não adianta você querer que ele seja dedicado a ti, ele sempre vai fechar com outro quase ao mesmo tempo. Porém ele não deixa de ser um amigo, só que somente com ele, não tem rolê. Atualmente ele serve bem para um contexto geral, quando falamos de serviços de e-mail, compartilhamento de dados que não precisem de correções ou rebalanceamento de carga, mas nunca funcionaria sozinho para um serviço tipo Spotify, por n motivos.
O amoroso, Model-View-Controller
Ah, o MVC. Continuando com analogias toscas de personagens masculinos, o MVC seria aquele galã de filme de comédia romântica. Estamos falando do Cauã Reymond das arquiteturas. Se antes tínhamos uma relação poliamorosa intensa, agora teremos um amorzinho calmo. O padrão (muito padrão) MVC vai trabalhar com apenas 3 camadas. A camada de modelagem, onde ele vai separar a parte de dados lógicos e organizacionais da aplicação, objetos, enums, constantes e afins. A camada de visualização, a parte que terá contato com o público, páginas, widgets, componentes e por fim a parte controladora do boy, que irá fazer o intermédio de gravação de dados, acesso a outras api's e serviços. Simples, carinhoso, correto. O cara que todas querem, né? é, até cair nas limitações que esse cara nos traz. Imagina aquele sisteminha hipopótamo que estamos utilizando até agora. Dificilmente esse cara não irá nos dificultar servir a todas aquelas requisições. Vai ser sempre um problema de DR para coisas que apenas uma manutenção de código deveriam resolver, e o boy é fresco. Com tudo ele desabará. Então, se você gostar de um sisteminha calmo, simples, sem muitas emoções, esse cara é pra casar. Caso contrário, vamos trabalhar com o próximo.
O ocasional, Event Bus
Suponhamos que você não deseje uma relação verdadeiro e trabalhe com uma conveniência. Serviços por conveniência, recursos por conveniência… você entendeu. Em alguns momentos, parte do seu projeto vai estar desativado, fingindo que não é com ele. Suponhamos que para conseguir isso, você apenas aloque seus serviços em um único espaço, mas que faça a parada parecer verdadeira quando por baixo dos panos você gerencia que o seu relacionamento só exista por eventos. Quando requisitado. Utilizando aquele sisteminha hipopótamo que já pensamos anteriormente, vamos imaginar que a gravação da mídia não irá ser feita recorrentemente e assim, podemos desligar a parte de inserção de dados e economizar uns dólares na AWS até a próxima temporada do Grammy (todo dia um indie chato lança uma música voz e violão para uma adolescente chata baixar, mas utilize a imaginação) a sua arquitetura teria que utilizar meios definidos para adormecer e acordar esse cara a todo evento do Grammy que vocês tiverem que participar, rs.
O perigoso, Blackbound
Um gosto.. quer dizer, um serviço robusto e com características peculiares. O padrão professor é utilizado para resolver problemas que por ocasiões não se sabe qual vai ser a sua resolução. Estamos falando de sistemas que dependem de cálculos e escolhas de inteligência artificial, ciência de dados e processamentos de imagem. Esse padrão é um super padrão que terá que servir a todo tipo de problema, e casar muito bem com todo tipo de problema. Essa aplicação irá centralizar serviços de diferentes resultados e separar seus controladores, muitas vezes em abundância, para abranger todas as suas necessidades. Utilizando nosso sisteminha, ele seria capaz de prover todas as músicas de uma vez só para você, se assim você quisesse. O problema dele? ah ele só tem um problema. Ele muitas das vezes é caro ao extremo, então você na sua pequenez só irá admirar essa beleza de padrão. Além disso, o risco desse serviço cair, por sua centralização de processos é gigante, saindo assim de cena quando uma nova oferta acontecer.
A divina, Micro-serviços
Ah o Micro-serviço, o que falar né? a paixão de todos os arquitetos. Se popularizou entre os anos de 2015 até agora, mesmo fazendo hiato, continua sempre em alta. Virou a meta de vida de muitos techleads por ai. A decisão de se criar um sistema de micro-serviços vem dessa necessidade de ter espontaneidade, inovação, rápidas modificações e correções, com o crescimento contínuo e máxima performance durante seu show. Não é um relacionamento, é uma devoção. Porém como toda religião, essa deusa requer sempre muito dos seus súditos. Seja em provisionamento, em decisões, em complexidade de desenvolvimento. Essa rainha será cara para seu projeto, então deve-se escolher bem quando a aplicar. As vantagens são claras, quando dividimos por módulos as funcionalidades. Temos manutenções rápidas, fáceis detecções de erros, rápidas integrações com novas funcionalidade e a aplicação de diferentes contextos e provisionamentos em diferentes períodos. Porém, nem essa deusa é unânime. Vários projetos possuem fracasso com a utilização de micro-serviços. Muitos por falta de senso ao tentar utilizar tamanho poder em pequenas soluções. O problema não é dela se o seu orçamento é pequeno…
Esses são alguns dos padrões que geralmente são utilizados em projetos comerciais. Existem diversos tipos de arquiteturas, com diversas finalidades, com diversas características que com certeza se encaixarão em algum dos seus projetos. Então nada de inventar a roda, e querer definir uma arquitetura própria (e muito provavelmente errada) ou pior, não utilizar arquitetura nenhuma e criar um sistema solteiro.
Para mais informações sobre arquiteturas, segue a call da galera logo abaixo:
Em português:
- https://www.zappts.com/blog/arquitetura-monolitica-e-microsservicos/
- https://guia.dev/pt/pillars/software-architecture/layers.html
- https://www.digitalhouse.com/br/blog/arquiteturadesoftware/#:~:text=A arquitetura de software de,um sistema pode ser desenvolvido.
Em inglês:
- https://www.geeksforgeeks.org/types-of-software-architecture-patterns/
- https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
- https://www.turing.com/blog/software-architecture-patterns-types/
obs: Caso você não tenha entendido a referência dos 7 maridos e o porquê da Queen B. ser a sétima.
Críticas, reclamações, opiniões adversas, lembrem-se. Guardem pra si, eu não tô nem ai. Um beijo da Anitta.
Top comments (0)