Resumo Executivo

Nadine Meyer Ouro; Marcos Jardel Henriques

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

O desenvolvimento de aplicações web modernas experimenta transformações significativas com a adoção de arquiteturas de micro frontends, uma abordagem que permite maior modularidade, escalabilidade e autonomia no desenvolvimento de interfaces de usuário (Geers, 2020). Essa estratégia arquitetural representa uma evolução natural dos microsserviços aplicada ao frontend, fragmentando aplicações complexas em unidades menores e mais gerenciáveis, nas quais diferentes equipes podem desenvolver, testar e implementar funcionalidades de forma independente (Mezzalira, 2021). A arquitetura de micro frontends emergiu como resposta aos desafios de escala enfrentados por grandes organizações digitais no final dos anos 2000, quando as limitações das abordagens monolíticas se tornaram evidentes em contextos de desenvolvimento colaborativo com múltiplas equipes (Pavlenko et al., 2020). A necessidade de permitir que diferentes times trabalhassem de forma autônoma, utilizando tecnologias distintas e ciclos de desenvolvimento independentes, levou ao desenvolvimento deste novo paradigma que descentraliza o desenvolvimento de interfaces, de forma análoga ao impacto dos microsserviços nos sistemas de backend (Yang et al., 2019). No contexto específico de micro frontends, emerge um desafio crítico relacionado ao gerenciamento de propriedade dos componentes compartilhados entre diferentes equipes. Este problema torna-se particularmente complexo quando elementos de interface precisam ser utilizados em múltiplos contextos, páginas e domínios funcionais. A literatura apresenta abordagens distintas para esta questão, como o Domain-Driven Design, que defende a organização por domínios funcionais com contextos delimitados bem definidos (Evans, 2004). Por outro lado, abordagens focadas em topologias de times propõem a existência de equipes de plataforma especializadas em fornecer componentes padronizados para o restante da organização (Skelton e Pais, 2019). Essas diferentes perspectivas refletem uma tensão fundamental entre equilibrar a independência operacional das equipes e a coesão visual e funcional do produto final. Estudos recentes corroboram essa complexidade, indicando que, embora a descentralização acelere o desenvolvimento, ela pode comprometer a consistência do sistema (Peltonen et al., 2021). A investigação empírica de estratégias de gestão de responsabilidades, como o modelo por domínio de negócio e o modelo compartilhado, permite compreender como esses padrões impactam a performance de aplicações distribuídas e a produtividade das equipes envolvidas.

A investigação caracterizou-se como uma pesquisa experimental aplicada, com foco na análise dos impactos de diferentes estratégias de propriedade em arquiteturas de micro frontends (Wohlin et al., 2012). Para a execução do experimento, desenvolveram-se dois protótipos funcionais de uma aplicação frontend, cada um representando uma estratégia organizacional distinta. O contexto escolhido foi a simulação de uma Página de Produto típica de sistemas de comércio eletrônico, composta por informações do produto, como título, descrição, preço e imagens, além de um componente de cálculo de frete e prazo de entrega. No Protótipo A, correspondente ao modelo de responsabilidade por domínio de negócio, a equipe de produto manteve controle total sobre a página, incluindo a integração e a apresentação visual. Embora a lógica de cálculo de frete permanecesse sob responsabilidade do domínio de logística, sua interface foi desenvolvida localmente pelo time de produto. Já no Protótipo B, que representa o modelo de componentes compartilhados, a página utilizou um componente de frete fornecido como uma biblioteca pelo domínio de logística, com lógica e interface pré-definidas, consumido como uma unidade fechada. O desenvolvimento dos protótipos utilizou React 18 como framework principal e Next.js para renderização e roteamento. A estrutura do projeto foi organizada em um monorepositório utilizando Turborepo, o que facilitou a gestão de múltiplos pacotes e aplicações. A linguagem TypeScript foi empregada para garantir segurança de tipos e produtividade. Para simular um ambiente corporativo real, a biblioteca compartilhada de componentes de frete do Protótipo B foi publicada no GitHub Packages, permitindo o consumo via instalação de pacote npm de forma independente. A modularização foi implementada por meio de diretórios específicos para aplicações e pacotes, simulando micro frontends com dependências externas gerenciadas via registro público. O processo de implementação seguiu cinco etapas: planejamento do escopo funcional, desenvolvimento do Protótipo A, desenvolvimento do Protótipo B, simulação de cenários e coleta de dados. Quatro cenários foram propostos para comparação: correção de erro em componente mantido por outro time, aplicação de novo design visual, evolução funcional com a funcionalidade de retirada em loja e alteração visual imposta pela equipe mantenedora. As métricas coletadas incluíram o tempo de desenvolvimento, medido por cronometragem manual e análise de histórico de commits, o número de arquivos alterados, a quantidade de interações entre equipes, além de avaliações qualitativas sobre autonomia, facilidade de manutenção e consistência visual (Bass et al., 2021).

A execução do primeiro cenário, focado na correção de um erro no componente de frete, revelou disparidades operacionais entre os modelos. No Protótipo A, o erro pôde ser corrigido diretamente pelo time de produto em apenas 15 minutos, envolvendo a alteração de um único arquivo e o deploy imediato, sem necessidade de coordenação externa. No Protótipo B, a correção exigiu que os desenvolvedores do time de logística atuassem na biblioteca compartilhada, alterando três arquivos em 15 minutos, seguidos por mais cinco minutos para que o time de produto atualizasse a versão da dependência e realizasse o novo deploy. O tempo total de 20 minutos no Protótipo B representou uma duração 33% superior em relação ao Protótipo A. Esses resultados corroboram as observações clássicas sobre como a estrutura organizacional influencia a arquitetura do software (Conway, 1968). A estratégia de domínio de negócio demonstrou maior agilidade para resoluções locais, alinhando-se aos princípios de propriedade que favorecem a velocidade (Skelton e Pais, 2019). Contudo, a abordagem de componente compartilhado, apesar de mais lenta devido à coordenação, centraliza a manutenção em especialistas, o que pode reduzir a duplicação de esforços em larga escala (Evans, 2004). A necessidade de comunicação entre times no Protótipo B adicionou uma etapa burocrática ao processo, impactando a velocidade de entrega, conforme discutido em estudos sobre performance de equipes de software (Forsgren et al., 2018).

No segundo cenário, que envolveu a aplicação de um novo design visual à página de produto, o Protótipo A permitiu que o time de produto aplicasse as mudanças de forma unificada em 30 minutos, modificando sete arquivos sem interações externas. No Protótipo B, o processo foi fragmentado: o time de produto alterou a página em 25 minutos, mas o componente de frete permaneceu com o visual antigo, gerando inconsistência. Foi necessário solicitar ajustes ao time de logística, que levou cinco minutos para atualizar a biblioteca, e outros cinco minutos foram gastos pelo time de produto para a atualização da dependência. O esforço total de 35 minutos e as duas interações entre equipes evidenciaram um trade-off entre flexibilidade local e consistência global. Embora o Protótipo A tenha oferecido maior rapidez e coesão estética imediata, o Protótipo B garantiu que a alteração fosse implementada de forma centralizada, assegurando que o componente mantivesse o mesmo padrão em todos os contextos de uso da aplicação. Essa dinâmica reflete os desafios práticos de componentes reutilizáveis na manutenção da consistência visual (Frost, 2016). A necessidade de sincronização no modelo compartilhado aumentou a complexidade operacional, mesmo com tempos totais de execução comparáveis.

O terceiro cenário abordou a evolução funcional com a inclusão da funcionalidade de retirada em loja. No Protótipo A, a implementação levou 12 minutos e exigiu uma interação para alinhamento de requisitos, mas a responsabilidade total pela apresentação ficou com o time de produto. Identificou-se, entretanto, um risco elevado de fragmentação visual, pois outras páginas poderiam implementar a mesma funcionalidade de maneiras distintas. No Protótipo B, a funcionalidade foi implementada centralizadamente pelo time de logística em 12 minutos e propagada para o time de produto em dois minutos por meio de atualização de versão. O tempo total de 14 minutos foi ligeiramente superior, mas a atualização não exigiu conhecimento técnico específico de logística por parte do time de produto. Este resultado reforça a importância de evitar a repetição de lógica e interface em escala organizacional (Hunt e Thomas, 1999). O modelo compartilhado demonstrou superioridade na distribuição de responsabilidades especializadas, enquanto o modelo de domínio de negócio priorizou a rapidez local em detrimento da padronização sistêmica. A necessidade de incorporar demandas externas ao cronograma do time de produto no Protótipo A pode gerar conflitos de priorização que retardam a evolução do sistema como um todo.

No quarto cenário, uma alteração visual imposta pela equipe mantenedora do componente de frete foi simulada. No Protótipo A, o time de produto precisou interpretar novas diretrizes e aplicar as mudanças manualmente em 15 minutos, alterando quatro arquivos e exigindo uma interação para compreensão do contexto. No Protótipo B, o time de logística realizou a alteração na biblioteca em 10 minutos e o time de produto apenas atualizou a dependência em dois minutos. O tempo total de 12 minutos no Protótipo B foi 20% menor que no Protótipo A. Mais importante que a economia de tempo foi a eliminação da necessidade de interpretação e reimplementação de diretrizes pelo time consumidor. Este cenário evidenciou a eficiência do controle centralizado para disseminar mudanças em escala, corroborando benefícios descritos em padrões de arquitetura empresarial (Fowler, 2003). O modelo compartilhado reduziu problemas de comunicação e sincronização que são comuns em organizações com múltiplas equipes (Brooks, 1975). A análise quantitativa geral indicou que o Protótipo A teve um tempo médio por cenário de 18 minutos, enquanto o Protótipo B registrou 20,25 minutos. O tempo total para os quatro cenários foi de 72 minutos para o modelo de domínio e 81 minutos para o modelo compartilhado. O número médio de arquivos alterados foi de 3,5 no Protótipo A contra 5,5 no Protótipo B, e o total de interações inter-equipes foi significativamente menor no Protótipo A, com apenas duas interações frente a cinco no Protótipo B.

Qualitativamente, o Protótipo A demonstrou alta autonomia para mudanças locais, alinhando-se aos princípios de equipes autônomas (Kniberg e Ivarsson, 2012). O tempo médio 11% menor e a redução drástica nas interações confirmam essa independência operacional. Por outro lado, o Protótipo B simplificou as atualizações centralizadas e garantiu a padronização, eliminando a necessidade de conhecimento técnico profundo sobre domínios externos por parte das equipes consumidoras. No que tange à complexidade organizacional, o modelo de componentes compartilhados exigiu maior maturidade nos processos de governança e comunicação, confirmando observações sobre a relação entre complexidade arquitetural e organizacional (MacCormack et al., 2006). As limitações do estudo incluem o ambiente controlado e o escopo reduzido a quatro cenários, o que impede a generalização total dos achados para projetos de grande porte em produção. A expertise das equipes também não foi variada, fator que poderia alterar os resultados de tempo e qualidade. No entanto, os dados obtidos fornecem evidências concretas sobre os trade-offs envolvidos em cada escolha arquitetural. A decisão entre os modelos deve ser pautada pela frequência de mudanças esperada e pela capacidade de governança da organização.

Conclui-se que o objetivo foi atingido ao demonstrar que não existe um modelo de responsabilidade universalmente superior, mas sim vantagens distintas dependentes do contexto e da origem das demandas. O modelo por domínio de negócio mostrou-se mais eficiente para correções rápidas e customizações locais, proporcionando maior agilidade e autonomia às equipes. Em contrapartida, o modelo de componentes compartilhados revelou-se superior para a propagação centralizada de mudanças e manutenção da consistência visual em escala, simplificando o processo para os times consumidores ao custo de um maior esforço de coordenação e governança. A escolha entre as estratégias deve considerar a distribuição de responsabilidades, a necessidade de padronização e a maturidade organizacional para comunicação entre times.

Referências Bibliográficas:

Bass, L.; Clements, P.; Kazman, R. 2021. Software Architecture in Practice. 4ed. Addison-Wesley Professional, Boston, MA, Estados Unidos.

Brooks, F. 1975. The Mythical Man-Month. 1ed. Addison-Wesley Professional, Boston, MA, Estados Unidos.

Conway, M. E. 1968. How do committees invent? Datamation 14(4): 28-31.

Evans, E. 2004. Domain-Driven Design: Tackling Complexity in the Heart of Software. 1ed. Addison-Wesley Professional, Boston, MA, Estados Unidos.

Forsgren, N.; Humble, J.; Kim, G. 2018. The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. 1ed. IT Revolution, Portland, OR, Estados Unidos.

Fowler, M. 2003. Patterns of Enterprise Application Architecture, Addison-Wesley Professional, Boston, MA, Estados Unidos.

Frost, B. 2016. Atomic Design. 1ed. Brad Frost Web, Pittsburgh, PA, Estados Unidos.

Geers, M. 2020. Micro Frontends in Action. Simon and Schuster, Shelter Island, NY, Estados Unidos.

Hunt, A.; Thomas, D. 1999. The Pragmatic Programmer: From Journeyman to Master. 1ed. Addison-Wesley Professional, Boston, MA, Estados Unidos.

Kniberg, H.; Ivarsson, A. 2012. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. Disponível em: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf. Acesso em: 10 jun. 2025.

MacCormack, A.; Rusnak, J.; Baldwin, C. 2006. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Management Science 52(7): 1015-1030.

Mezzalira, L. 2021. Building Micro-Frontends. O’Reilly Media, Inc., Sebastopol, CA, USA.

Pavlenko, A.; Askarbekuly, N.; Megha, S.; Mazzara, M. 2020. Micro-frontends: Application of microservices to web front-ends. Journal of Internet Services and Information Security 10(2): 49-66.

Peltonen, S.; Mezzalira, L.; Taibi, D. 2021. Motivations, benefits, and issues for adopting micro-frontends: a multivocal literature review. Information and Software Technology 136: 106571.

Skelton, M., Pais, M. 2019. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, Portland, OR, Estados Unidos.

Wohlin, C.; Runeson, P.; Höst, M.; Ohlsson, C., Regnell, B.; Wesslén, A. 2012. Experimentation in software engineering. Berlim, BE, Alemanha.

Yang, C.; Liu, C.; Su, Z. 2019. Research and application of micro frontends. IOP Conference Series: MaterialsScience and Engineering 490(1):1–8.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy