Fronteiras entre feature, shared e design system

O problema

Muita estrutura de frontend vira teatro organizacional.

Você abre a árvore e vê:

• features/
• shared/
• design-system/

Tudo parece sério.

Mas no uso real:

• shared recebe qualquer coisa que ninguém sabe onde pôr
• design-system vira ponto de exceção de produto
• uma feature importa coisa de outra por conveniência

No fim, a pasta está bonita e a fronteira continua ruim.

Modelo mental

Esses nomes não deveriam representar estética.

Eles deveriam representar níveis diferentes de contrato.

Uma forma prática de pensar:

• feature = código que existe para resolver um fluxo ou caso de produto específico
• shared = código reaproveitável entre features, mas ainda sem virar contrato visual/base do sistema
• design system = tokens, padrões e componentes com contrato estável e responsabilidade clara de consistência

Em frase curta:

a pergunta não é “em que pasta cabe?”. A pergunta é “qual é o escopo real e quão estável isso precisa ser?”.

Quebrando as fronteiras

O que costuma ficar em feature

Fica em feature o que ainda é fortemente ligado ao contexto daquele fluxo.

Exemplos:

• componentes da tela de checkout
• regra de combinação de filtros daquela listagem
• copy específica do onboarding
• estado e composição daquele domínio

Mesmo que o código esteja bonito.

Mesmo que talvez seja reutilizável no futuro.

Se o valor dele ainda depende daquele contexto, deixar local costuma ser mais saudável.

O que costuma ir para shared

Shared é o meio do caminho.

Serve para coisas que:

• aparecem em várias features
• têm utilidade transversal
• ainda não são parte do contrato central de UI do produto

Exemplos:

• helpers de data
• wrappers de integração
• pequenos blocos reutilizáveis de tela
• hooks transversais que não pertencem ao design system

O risco aqui é transformar shared em lixão.

Se tudo vai para lá, nada tem dono claro.

O que realmente merece design system

Design system deveria carregar o que precisa ser consistente, previsível e estável.

Exemplos:

• tokens
• primitives
• componentes base de formulário
• feedback visual padronizado
• regras de acessibilidade e interação recorrentes

O erro clássico é subir exceção de produto cedo demais.

Quando isso acontece, o design system vira um catálogo de casos especiais com props infinitas.

Exemplo simples

Imagine um badge de status.

Cenário 1:

• só aparece em um fluxo de faturamento
• tem regra específica daquele contexto
• ainda está mudando de significado

Isso provavelmente é feature.

Cenário 2:

• aparece em várias telas internas
• reaproveita comportamento simples
• ainda não define linguagem visual central do produto

Talvez seja shared.

Cenário 3:

• virou padrão visual recorrente
• precisa seguir tokens e acessibilidade de forma consistente
• já tem semântica clara e estados estáveis

Aí começa a parecer design system.

O teste que costuma ajudar

Antes de mover código, vale perguntar:

1. isso é específico de um fluxo?
2. isso é útil em vários pontos sem depender do domínio original?
3. isso virou contrato estável de interface e consistência?

As respostas normalmente apontam o destino melhor do que qualquer convenção de pasta.

Erros comuns

• Subir para shared tudo que gerou desconforto local.
• Empurrar componente prematuro para o design system.
• Criar fronteira por cargo cult, sem regra de decisão.
• Deixar feature depender de feature e chamar isso de pragmatismo.

Como um senior pensa

Quem olha bem para arquitetura de frontend costuma ser conservador na promoção de código.

O raciocínio saudável geralmente é:

• primeiro deixa local
• depois observa repetição real
• só então promove para shared
• e só promove para design system quando o contrato já ficou estável

Isso evita dois custos ruins:

• abstração cedo demais
• consistência falsa baseada em componente genérico demais

Ângulo de entrevista

Esse tema aparece muito em:

• arquitetura frontend
• system design focado em produto web
• code review de base grande

Resposta fraca:

eu separaria em feature, shared e design system

Resposta forte:

• explica o critério de promoção
• mostra que estabilidade importa
• diferencia reutilização transversal de contrato central

É isso que passa maturidade.

Fechando a ideia

Feature, shared e design system só ajudam quando representam fronteiras reais.

Se viram só decoração de pasta, o time ganha uma árvore mais bonita e uma base igualmente confusa.

Estrutura boa não é a que parece organizada. É a que deixa claro o que ainda é local, o que já virou utilidade transversal e o que realmente merece contrato estável.