Arquitetura de Software: Além das Siglas
Há algum tempo penso em escrever sobre arquitetura de software especificamente voltada a aplicações móveis. Eis que surgiu uma oportunidade de falar sobre este tema no evento Dev Summit — Edição Speedy da igti no dia 22/02/2022. Estou publicando este post como base e complemento para a talk
Vídeo da talk:
Objetivos
O intuito do post não é indicar uma arquitetura x ou y, um pattern a ou b e sim reforçar alguns pontos e boas práticas, além de trazer alguns cases e exemplos reais baseados nestas práticas.
“A arquitetura é uma hipótese que precisa ser comprovada por implementação e medição.”
- Tom Gilb
Tom Gilb é um engenheiro, consultor e autor americano de sistemas, conhecido pelo desenvolvimento de métricas de software, inspeção de software e processos evolutivos.
Gostaria de começar com meu motivador, que são Cultura, Organização projetos de software, escala e replicação. Participei ao longo da minha carreira de diversos projetos com tamanhos variados tanto de equipe quanto de complexidade em empresas com cultura de órgão publico a startups de pequeno e grande porte.
Aquele desenho com várias caixinhas e um monte de ligações entre elas.
Em meados de 2009, quando trabalhava como desenvolvedor PHP (sem piadinhas ok?), em uma instituição de ensino, recebi a tarefa de melhorar uma funcionalidade de requerimentos do sistema. Estudava a fundo JavaScript e havia comprado um livro de jQuery, pois queria implementar algo mais "moderno" no sistema. Pois bem, apresentei a idéia para o arquiteto do produto na época (um salve Henrique!) e ele me deu ok, mas, com uma condição: que eu criasse a documentação de uso e diagramas UML e de Arquitetura do que eu estava implementando.
Usei meu cartão de aluno da universidade e fui buscar livros sobre UML. Infelizmente, não me recordo exatamente o nome do livro para compartilhar com vocês, mas era antigo sem sombra de dúvidas.
Mas voltando ao tema: a UML (do inglês Unified Modeling Language, em português Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de projetos de software.
Como este post é de um contexto mais geral independente do nível de senioridade, fica a pergunta: você já parou alguns momentos e refletiu sobre como foi pensado o software e/ou aplicativo em que você está trabalhando hoje? Você usa UML? Já viu algum na sua frente? Já criou algum?
Porque fiz estes questionamentos? Pois é por UML que pretendo iniciar esta jornada com vocês. A UML fornece uma série de elementos visuais que são usados em diferentes gráficos para representar os componentes da aplicação.
Existem programas que geram código JAVA a partir do UML como, por exemplo, Astah, ferramenta que foi fortemente utilizada para este fim e que possuía uma versão simplificada gratuíta para a comunidade.
Vejo que hoje com os movimentos ágeis, talvez mal interpretados dentro das empresas, que algumas práticas foram deixadas de lado devido a prazos apertados e time com fome de código.
Veja bem, sou um profissional que estudou muito Scrum e um dos valores descritos no manifesto ágil é:
Concordo mas não quero que você interprete isso de forma a não documentar nada.
Pense em você entrando em uma empresa nova com um sistema gigantesco onde não existe uma documentação ou algum diagrama qualquer que explique como o aplicativo funciona e se comunica com outros serviços. Você dependerá de um colega que está na empresa há anos e que manja tudo do sistema e ele vai te explicar tudo.
Acredito que muitos que estão lendo já passaram por isso.
Lembra do desafio que o Henrique me passou?
Cerca de 10 anos depois que saí da instituição encontrei um grupo de devs que estava dando manutenção neste mesmo sistema e que me reconheceram pelo nome que estava nos headers e documentações e que ainda utilizavam a documentação que havia criado.
Ok, você pode agora pensar e dizer: Hun.. UML é muito complexo e não vai agregar no momento atual para o projeto.
Não vou me aprofundar mais e vamos seguir em frente para chegarmos na parte bacana.
Vamos para outro ponto ainda visual?
C4 model
Criado por Simon Brown, o C4 model tem o propósito de resolver e clarificar a visualização de arquitetura de software para públicos e propósitos diferentes. Consiste em um conjunto hierárquico de diagramas de arquitetura de software.
O nome C4 vem dos quatro “níveis” de diagrama propostos pelo autor.
- Contexto
- Containers
- Componentes
- Classes/Código
Aqui é temos um exemplo de diagrama de componentes:
Um componente é um conjunto de funcionalidades encapsuladas atrás de uma interface bem-definida.
A apresentação deste exemplo em específico torna o entendimento muito mais claro não concorda? E é um bom exemplo de diagrama a ser feito caso seja um projeto inicial ou algum legado que você está assumindo.
Tive oportunidade de trabalhar em uma empresa bem reconhecida no mercado e que possuía ainda algumas partes do aplicativo sem ter um diagrama compartilhado com o time, que vamos chamar de Time A. Os devs backend do Time A tiveram um empenho fantástico em reservar uma hora praticamente todos os dias para abrir o código, passar por todo o fluxo de uma das partes do serviço no qual o éramos responsáveis e desenhar as partes que estavam faltando. Vale ressaltar que enquanto eles estavam produzindo esta documentação, o Time B precisava usar um microsserviço que era de responsabilidade do Time A, mas que ainda não estava documentado. Não vou comentar a estratégia que tomamos ao invés disso vou deixar mais um questionamento para você.
O que você vê fazendo mais sentido?
- Marcar uma ou mais reuniões de uma a duas horas para que o especialista explique o funcionamento para o Time B?
- Priorizar a documentação e o desenho deste microsserviço e publicar em uma plataforma interna da empresa para que todos possam consumir, sendo necessário talvez gravar um vídeo com uma breve explicação mais técnica de ambiente e configurações ou uma agenda de 30 minutos para passar informações especificas para um time mais novo na empresa?
Existem outras opções, mas como disse no inicio, não estou aqui para te dizer o que é certo ou errado. Suas decisões são baseadas na realidade do seu time e produto e quero lhe mostrar as opções e boas práticas que considero de excelência hoje em dia.
Visão de Liderança 2022 para Líderes de Engenharia de Software
O trecho abaixo foi retirado de um material da Gartner bem atual vou deixar o link na bibliografia deste post.
Enfatize a granularidade para maximizar a capacidade de composição e otimizar a arquitetura.
Falei a pouco sobre microsserviços e este material aborda este tema também. Arquiteturas utilizando microsserviço vão um pouco mais além e envolvem arquiteturas de soluções que acabam aprofundando mais sobre o negócio.
Quero trazer mais sobre os microsserviços pois este tipo de arquitetura está no mundo mobile também.
Microservices
No final dos anos 2000 empresas como Netflix e Amazon enfrentaram os desafios de construir software em grande escala. Buscando minimizar o atrito de centenas de colaboradores, onde todos faziam alterações em enormes bases de código compartilhadas, eles dividiram o software em serviços que poderiam ser implantados e dimensionados isoladamente em hardware alugado na nuvem.
Vou trazer um trecho do que Adrian Cockcroft falou sobre o processo de criação dos microsserviços da Netflix:
Então não foi apenas uma migração em massa de uma só vez?
Não.(…)Você tem que construir coisas de forma incremental, por isso é muito orgânico e é uma arquitetura emergente. Não foi projetado centralmente. É o que qualquer um precisava fazer no momento. E muita conversa sobre coisas para que as más ideias sejam erradicadas e sejam entendidas como “evitar isso”.
Atualmente, os times de desenvolvimento mobile enfrentam os mesmos desafios de escala e conflitos que estes gigantes enfrentaram.
Microapps architecture
Empresas como SoundCloud, Just Eat, LuvPet (projeto pessoal heheh ) com base em talks que já assisti e conversas que tive com devs das empresas, aqui no Brasil, temos abordagens similares em empresas como iFood, Banco Inter, Nubank, Spotify, dentre outras. Estas empresas têm explorado uma abordagem semelhante a microsserviços. Isolando módulos em bases de código dedicadas é possível evitar longos tempos de build e execução de testes isolados, podendo, assim, fornecer ciclos de feedback mais rápidos.
Pretendo abordar mais profundamente em outras talks e posts este tema voltado a plataforma iOS.
Como qualquer padrão de arquitetura, a abordagem de microaplicativos traz compensações. Os microsserviços influenciaram fortemente a arquitetura de microaplicativos, mas há uma diferença fundamental entre os dois:
Os microsserviços são implantados individualmente, enquanto os módulos que formam um aplicativo de microaplicativos são compilados no mesmo binário. Essa restrição tecnológica limita a liberdade que as equipes individuais têm ao escolher como construir seus módulos.
Abaixo um exemplo simples no qual foi criado juntamente com o time de desenvolvimento iOS de um projeto no qual trabalhei. A idéia foi entendermos a atual arquitetura de um projeto legado e conseguir dar suporte a navegação via rotas e UniversalLinks. Usamos o aplicativo draw.io para desenhar um Fluxograma para este entendimento. Conseguimos separar inclusive em fases que, posteriormente, foram direcionadas para nossas
Sprints, sendo uma boa forma de apresentar para os stakeholders o que precisaríamos modificar e dar o suporte às solicitações futuras.
O resultado disso foi um processo de quebra de um app em monolito para um app modular. E que, posteriormente, em um novo projeto nos permitiu ter conhecimento técnico e entendimento das funcionalidades e macetes para iniciar do zero já com uma arquitetura modular e sem bibliotecas externas. E o melhor de tudo, para quem desenvolve aplicativos para Apple, é diminuir muito os conflitos de projetos no Xcode como, por exemplo, o famigerado .pbxproj
Repare na organização abaixo:
Poucos arquivos estão na estrutura principal do projeto. Scenes, padrões de UI e Foundations foram quebradas em módulos para melhor organização e manutenção dos códigos existentes.
Permita a contingência de features
Permita a contingência de features, prevenindo paradas por causa de falhas, e, para isso, existem algumas técnicas como, por exemplo, Remote configs e feature toggles. Em resumo, são chaves e valores que permitem, via um sistema externo, habilitar ou não a exibição de alguma feature no Software.
Digamos que os deploys de serviço e aplicativos não são feitos com a mesma cadência e por algum motivo um deploy de um serviço foi feito em produção e que acabou quebrando um fluxo no aplicativo.
Você pode reverter a modificação do seu serviço ou desabilitar temporariamente a feature até que a versão mobile entre com a nova versão, ou direcionar para alguma página web também caso o problema ocorra.
Sabemos que o deploy de uma versão para as lojas de aplicativo não é tão rápido como publicar um serviço.
É importante que estes pontos sejam levados em consideração na sua arquitetura também.
Vantagens da Arquitetura Adequada
- Testável
- Sustentável
- Mutável
- Fácil de Desenvolver
- Fácil de Implantar
- Independente
DDD — Domain-Driven Design
"Quando a complexidade foge ao controle, os desenvolvedores já não podem entender o software bem suficiente para alterá-lo ou expandi-lo com facilidade e segurança."
— Eric Evans Domain-Driven Design
O livro de Eric Evans Domain-Driven Design influenciou profundamente o pensamento arquitetônico moderno. Domain-driven design (DDD) é uma técnica de modelagem que permite a decomposição organizada de domínios de problemas complexos.
- DDD não é uma arquitetura
- Entenda o negócio
- Conheça os Domain experts
- Extraia a(s) linguagem(ns) ubíqua(s) (fale a mesma língua do negócio)
- Defina uma arquitetura (não se prenda a número de camadas)
Concluindo a linha de pensamento
Meu intuito com este conteúdo é que o tema arquitetura de software seja visto com mais profundidade e não só como algumas siglas que você aprendeu em algum vídeo ou que algum colega comentou com você. Arquitetura de software é uma disciplina muito mais abrangente do que MVC, MVVM, VIPER e VIP que na realidade são padrões arquiteturais para camada de apresentação do usuário. Você vai encontrar nelas muitas das coisas que trouxe aqui.
Organize seus arquivos em pastas que fazem sentido, utilize nomes adequados para arquivos e classes, documente o essencial para que seus colegas saibam como as coisas funcionam, fale a mesma língua dos stakeholders, cliente e time de UI/UX e tenha entendimento do domínio do produto que está construindo.
Deixo uma única sugestão para vocês: Escrevam uma biblioteca ou um código open-source.
Por quê? Simples, você vai perceber que quem olha para seu projeto e/ou código entende o propósito e o que faz. Você vai precisar explicar como instalar, ter o manual de uso e configuração, além de colher feedback e melhorar cada vez mais. Quer um exemplo de como isso dá certo? Me recordo quando ouvi estes pontos falados pelo Gabriel Engel, CEO da Rocket Chat, em uma talk da Brazil JS em 2017 (link na bibliografia) e, a partir daí, comecei a escrever algumas bibliotecas open-source. Se você olhar meu GitHub vai encontrar algumas. A qualidade do código, README e documentação que você escreve muda consideravelmente.
Para onde ir agora?
Recomendo a leitura de livros como:
- Domain-Driven Design
- Implementando Domain-Driven Design
- O mítico homem-mês: ensaios sobre engenharia de software
- A leitura dos links da bibliografia é muito rica também.
Espero que esta leitura tenha lhe dado algum insight e inspirado e começar de algum lugar a melhorar o produto no qual você e seu time estão atuando. O conteúdo é vasto e você precisa ter dedicação e paciência.
E lembre-se:
“Andar por este caminho requer cuidado e atenção, consideração e observação, prática e princípio. Em um primeiro momento, isso pode parecer lento, mas tudo depende da forma de andar.”
“A única maneira de ir rápido, é ir bem.”
Robert C. Martin
Bibliografia
- Arquitetura Limpa Robert C. Marting — Editora Alta Books
- UML — Wikipédia
- O modelo C4 de documentação para Arquitetura de Software — InfoQ
- Padrões de Arquitetura de Aplicações Corporativas — Martin Fowler
- Meet the microapps architecture — Increment Post
- 2022 Leadership Vision for Software Engineering Leaders — Gartner
- Fundamentals of Software Architecture: An Engineering Approach — Mark Richards (O’Reilly)
- Gabriel Engel — Como um projeto JS open source se transformou em uma empresa de 60 milhões
- Modular iOS Architecture @ Just Eat
- SoundCloud: Leveraging frameworks to speed up our development on iOS
- Talking microservices with the man who made Netflix’s cloud famous — Derric Harris
- Explicitando os Componentes de um Contêiner usando C4 Model — Elemar Júnior
