Republicação: texto publicado originalmente no Medium em 22/02/2022. Conteúdo de apoio à talk no Dev Summit — Edição Speedy da IGTI, 22/02/2022.

Objetivos

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: disponível no contexto do evento acima (gravado no âmbito do Dev Summit).

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 público 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 ideia 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úvida.

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?

Por que fiz estes questionamentos? Porque é 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 gratuita para a comunidade.

Vejo que hoje, com os movimentos ágeis — talvez mal interpretados dentro das empresas — 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 é:

Software em funcionamento mais que documentação abrangente

Concordo, mas não quero que você interprete isso como “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: “Hmm… 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:

  1. Contexto
  2. Containers
  3. Componentes
  4. Classes/Código

*(No artigo original no Medium havia um exemplo visual de diagrama de componentes.)*

Aqui temos um exemplo de diagrama de componentes (referência textual): o post original ilustrava um diagrama no estilo C4; para um exemplo escrito com bom nível de detalhe, vale o artigo “Explicitando os componentes de um contêiner usando C4 Model” do Elemar Júnior — em especial a ideia de que 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 é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; em vez 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 específicas para um time mais novo na empresa?

Existem outras opções, mas como disse no início, 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; deixo o link na bibliografia deste post.

Mensagem-chave: enfatize a granularidade para maximizar a capacidade de composição e otimizar a arquitetura.

*(No Medium o artigo incluía um slide/figura do material da Gartner.)*

Falei há 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 porque 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.

Trecho do que Adrian Cockcroft falou sobre o processo de criação dos microsserviços da Netflix (resumo da entrevista no link acima):

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 projetada 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, hehe) — 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 à 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 ideia foi entendermos a atual arquitetura de um projeto legado e conseguir dar suporte à navegação via rotas e Universal Links. 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 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: 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.

Repositório de exemplo: github.com/micheltlutz/microappsarcexemple

Permita a contingência de features

Permita a contingência de features, prevenindo paradas por causa de falhas. 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 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 quanto 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 o suficiente para alterá-lo ou expandi-lo com facilidade e segurança.”
— Eric Evans, *Domain-Driven Design*

O livro de Eric Evans influenciou profundamente o pensamento arquitetural 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: 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:

Espero que esta leitura tenha lhe dado algum insight e inspirado a 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

Agradecimentos

  • Arthurito
  • Esposa

Vocês são fodas.

Referências e fontes

Artigos e materiais

  1. Dev Summit — Edição Speedy (IGTI) — evento em que a talk foi apresentada.
  2. Manifesto para Desenvolvimento Ágil de Software
  3. UML — Wikipédia
  4. Astah UML
  5. C4 model
  6. Explicitando os Componentes de um Contêiner usando C4 Model — Elemar Júnior
  7. O modelo C4 de documentação para Arquitetura de Software — InfoQ
  8. 2022 Leadership Vision for Software Engineering Leaders — Gartner
  9. Meet the microapps architecture — Increment
  10. Talking microservices with the man who made Netflix’s cloud famous — Derric Harris
  11. Amazon, microservices and the birth of AWS
  12. Modular iOS Architecture @ Just Eat
  13. SoundCloud: Leveraging frameworks to speed up our development on iOS — Part 1
  14. Gabriel Engel — Como um projeto JS open source se transformou em uma empresa de 60 milhões — Brazil JS (YouTube)
  15. microappsarcexemple — exemplo no GitHub

Livros

  1. *Arquitetura Limpa* — Robert C. Martin; Editora Alta Books
  2. *Padrões de Arquitetura de Aplicações Corporativas* — Martin Fowler
  3. *Fundamentals of Software Architecture* — Mark Richards e Neal Ford (O’Reilly)

Republicação

  1. Arquitetura de Software: Além das Siglas — versão original no Medium, 22/02/2022.