1 min de leitura ·

Clean Architecture no frontend: vale a pena ou é over-engineering?

Clean Architecture foi definida para backends e sistemas complexos. Aplicar no frontend, especialmente em projetos React, virou moda em alguns times. Vale a pena?

O argumento a favor

Separação de responsabilidades. Regras de negócio separadas de UI, que está separada de acesso a dados. Trocar React por Vue não exige reescrever a lógica. Testar a lógica sem montar componentes.

Escalabilidade de times. Em times grandes com múltiplas pessoas no mesmo codebase, fronteiras claras reduzem conflito.

O argumento contra

Frontend é inerentemente acoplado à UI. A lógica de um formulário, as validações, o estado de loading: separar isso agressivamente cria abstrações que não reduzem complexidade, só a movem.

Custo de boilerplate. Clean Architecture no frontend frequentemente gera 5 arquivos para funcionalidade que seria clara em 1.

React já tem suas abstrações. Hooks, Context, componentes reutilizáveis. O modelo mental do React já é uma arquitetura. Adicionar camadas por cima frequentemente conflita com o modelo nativo.

Quando faz sentido

Lógica de negócio complexa que poderia migrar de framework. Cálculos financeiros, simulações, regras elaboradas: isso faz sentido isolar.

Times grandes com domínios bem definidos. Para 2 devs numa startup, é over-engineering.

A conclusão pragmática

Aplique os princípios, não a arquitetura completa. Separação de responsabilidades sim. Camadas de abstração por arquitetura sim. Ports and adapters para um formulário de cadastro, não.

Você usa Clean Architecture no frontend?

Pilati

2 dias atrás

Clean Architecture foi definida para backends e sistemas complexos.

Quando a conversa no Brasil começa com Clean Architecture eu paro de confiar na pessoa na hora.

Clean Arch (como conhecemos) é uma das piores arquiteturas já criadas, e TODAS as vezes que presenciei, mal feita.

Você usa Clean Architecture no frontend?

Jamais, e nem no backend

obrenoalvim

Autor

2 dias atrás

Faz sentido a desconfiança. A maioria das implementações que vi virou uma bagunça de interfaces inúteis e abstrações que ninguém sabe para que servem. O argumento de separar regra de negócio de UI é válido em teoria, mas na prática o custo de manutenção costuma superar o benefício, especialmente em times menores. No frontend, fica ainda mais estranho: a UI é parte central da lógica do negócio, não um detalhe de infraestrutura. O que você costuma adotar no lugar?

Programmer404

3 dias atrás

Muita gente não sabe o que é clean code e clean architecture.

O que é arquitetura limpa afinal? É seguir uma regra? É seguir uma receita de bolo? Sinceramente em desenvolvimento não existe um padrão para isso, portanto esse assunto não faz sentindo para mim. Percebemos que algo é uma boa solução quando o código fala por si mesmo e o problema esta resolvido.

Esse assunto é muito relativo ao projeto.

No Fronto-end há código, se há código ele precisa ser mantido. Qual é a melhor forma de trabalhar com essa base de código? É preciso levar X variáveis em questão relativo ao projeto, equipe, gestão e objetivos. É muito comum criar componentes para reutilizar código. Isto é feito especialmente para manter o princípio de não se repetir, que por consequência deixa o código mais limpo com menos bugs e repetições. Ha princípios que seguimos em todos os projetos, afinal são princípios. E mesmo assim ainda depende do projeto... Na minha opinião não há uma definição clara para isto. Todo mundo fala algo diferente, com tradeoffs diferentes.

Eu sou a favor de cuidar com carinho do projeto. Quando fazemos isso, não criamos funções inúteis, revisamos e estabelecemos padrões de qualidade. Consequentemente temos uma arquitetura mais limpa e com menos ruído.

obrenoalvim

Autor

3 dias atrás

Concordo que é relativo, mas acho que o maior valor de arquiteturas como essa não é ser receita. É ser linguagem comum. Quando entro num projeto e alguém fala 'use case' ou 'repository', já sei onde olhar sem ler o projeto inteiro. Esse valor de comunicação é muito subestimado.

No frontend uso essa separação quando o projeto tem regra de negócio de verdade. Tela de CRUD simples? Componente direto, sem cerimônia. Lógica com múltiplos critérios e estados? Aí isolo mesmo. Contextual como você disse.