Todo projeto front-end começa simples. Uma tela aqui, um componente ali, um estado global “temporário” que nunca mais sai. De repente, meses depois, você tem um monólito confuso, difícil de manter, com regras espalhadas e ninguém mais sabe exatamente onde mexer sem quebrar algo.

Se isso soa familiar, relaxa — você não está sozinho.

Esse artigo é sobre isso: como estruturar front-end em larga escala sem virar um caos.

O momento em que tudo começa a dar errado

O problema não aparece no início.

Ele surge quando:

• múltiplos times começam a contribuir
• features passam a depender umas das outras
• regras de negócio começam a se duplicar
• performance começa a degradar

A partir daí, sem arquitetura clara, o projeto vira um Frankenstein.

E o pior: ninguém percebe até ser tarde.

Microfrontends: solução ou overengineering?

Microfrontends parecem a solução perfeita:

• times independentes
• deploy desacoplado
• escalabilidade organizacional

Mas aqui vai a real, sem romantização:

👉 Microfrontend resolve problema organizacional, não técnico.

Se você tem:

• um único time
• baixo volume de deploy
• domínio simples

Você provavelmente está criando complexidade desnecessária.

Agora, quando faz sentido:

• múltiplos times independentes
• domínios bem separados (ex: billing, dashboard, auth)
• necessidade de deploy independente

Aí sim começa a fazer sentido.

Caso contrário, você só trocou um monólito por vários mini-caos distribuídos.

Monorepo vs Multirepo: a briga eterna

Esse aqui é clássico.

Monorepo

Ferramentas como Nx e Turborepo trouxeram um novo nível de organização.

Vantagens:

• compartilhamento de código simples
• padronização entre projetos
• versionamento centralizado

Problema:

• pode virar um monólito disfarçado
• builds lentos (se mal configurado)

Multirepo

Cada projeto vive isolado.

Vantagens:

• independência total
• isolamento de falhas

Problemas:

• duplicação de código
• inconsistência entre projetos
• versionamento complexo

A decisão madura

Não existe resposta universal.

Mas uma boa heurística:

• times pequenos → monorepo
• times grandes e independentes → considerar multirepo ou microfrontends

DDD no front-end: sim, isso existe

Aqui começa o pulo do gato.

A maioria dos projetos front organiza código por tipo:

/components
/hooks
/services
/utils

Parece bonito.

Mas quebra completamente quando o sistema cresce.

Estrutura orientada a domínio

Em vez disso:

/domains
  /checkout
    /components
    /hooks
    /services
  /user
    /components
    /services

Agora você tem:

• isolamento de regras
• menos acoplamento
• maior previsibilidade

👉 Cada domínio vira quase um “mini sistema”

Separação de responsabilidades: o que quase ninguém faz direito

Esse é o ponto onde projetos escalam… ou quebram.

Uma boa arquitetura separa claramente:

UI (camada visual)

• componentes
• layout
• renderização

Lógica de negócio

• regras
• validações
• transformações

Estado

• cache
• sincronização
• comunicação com API

Exemplo prático (anti-pattern)

function Checkout() {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    fetch('/api/cart')
      .then(res => res.json())
      .then(data => {
        const total = data.items.reduce((acc, item) => acc + item.price, 0);
        setTotal(total);
      });
  }, []);

  return <div>Total: {total}</div>;
}

Aqui você tem:

• UI
• lógica
• fetch
• cálculo

Tudo misturado.

Versão estruturada

// domain/checkout/useCheckout.ts
export function useCheckout() {
  const { data } = useCart();

  const total = useMemo(() => {
    return data?.items.reduce((acc, item) => acc + item.price, 0) ?? 0;
  }, [data]);

  return { total };
}

// UI
function Checkout() {
  const { total } = useCheckout();

  return <div>Total: {total}</div>;
}

Agora sim:

• UI limpa
• lógica isolada
• fácil de testar
• fácil de escalar

O verdadeiro problema: falta de decisão

No fim das contas, o maior erro não é escolher errado.

É não escolher.

Projetos quebram porque:

• não existe padrão
• cada dev faz de um jeito
• decisões não são documentadas

O que times sêniores fazem diferente

Eles não começam pelo código.

Eles começam por perguntas:

• Qual o domínio do sistema?
• Quantos times vão mexer nisso?
• Qual o nível de independência necessário?
• Onde queremos chegar em 1 ano?

Arquitetura boa não é a mais moderna.

É a que resolve o problema certo com o menor custo possível.

Conclusão: menos hype, mais intenção

Microfrontends, monorepo, DDD…

Tudo isso é ferramenta.

O erro é usar como moda.

Se você quiser evitar um Frankenstein no seu front-end:

• pense em domínios, não em arquivos
• separe responsabilidades desde cedo
• evite complexidade antes da hora
• documente decisões

Porque no fim…

👉 código ruim você refatora
👉 arquitetura ruim você sofre por anos