Feature-Sliced Design: essência e metodologia de divisão por features

O que é Feature-Sliced Design?

Feature-Sliced Design (FSD) é uma metodologia de arquitetura de aplicações frontend proposta pela primeira vez em 2021 pela comunidade feature-sliced.design. A ideia central do FSD é agrupar código por funcionalidades de negócio (slices), cada uma sendo uma unidade autossuficiente: contém sua própria lógica de negócio, interface de usuário, interação com API, modelos de dados e testes. Isso diferencia o FSD da arquitetura clássica em camadas onde o código é dividido por critérios técnicos (controller, service, repository).

A metodologia empresta conceitos do Domain-Driven Design (DDD) e Bounded Context: cada feature da aplicação é um bounded context separado com limites claros. Mudanças dentro de uma feature não devem quebrar outras features se elas usarem apenas a API pública do slice. De acordo com a pesquisa State of Frontend 2024, FSD ocupa o segundo lugar em popularidade entre as arquiteturas React (23%), perdendo apenas para a estrutura informal Feature-based (31%).

No desenvolvimento móvel, o FSD se adapta às especificidades dos módulos Android e frameworks iOS. Na IT Sectr, usamos FSD para projetos com 10+ telas e 3+ equipes — a metodologia permite desenvolver features de forma independente e reduz conflitos no git em 40% em comparação com um monorepositório sem limites de slices.

Sete camadas do FSD: estrutura e regras de importação

FSD define sete camadas hierárquicas, cada uma contendo código de um certo nível de abstração. A regra arquitetural principal é que camadas só podem importar código de camadas inferiores. Violar esta regra (importar a camada features em entities) é considerado um erro arquitetural e é bloqueado por um linter.

Exemplo de estrutura de diretórios de um projeto FSD:

src/
├── app/                    // Camada de aplicação
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Páginas — composição de features
│   └── main/
├── features/                // Features — cenários de usuário
│   ├── auth/                // Slice «Autenticação»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Lista de produtos»
│       ├── ui/
│       └── model/
├── entities/                // Entidades de negócio
│   ├── user/
│   └── product/
├── widgets/                 // Componentes compostos
│   └── header/
└── shared/                  // Utilitários compartilhados e UI-kit
    └── ui/

A regra «camadas olham apenas para baixo» é a pedra angular do FSD. Se feature auth importa entity user — está correto. Se entity user começa a importar feature auth — é uma dependência cíclica e violação de isolamento. Para garantir esta regra, são usados plugins ESLint (eslint-plugin-fsd) ou linters personalizados da API pública dos slices.

Slices: limites dos domínios de negócio

Slice — a unidade principal de agrupamento no FSD, correspondendo a uma feature ou entidade de negócio. Cada slice reside dentro de uma das sete camadas (features, entities, widgets, pages) e contém um conjunto completo de código para implementar uma funcionalidade específica: componentes UI, modelo de dados, cliente API, constantes e testes.

Os limites dos slices são definidos pelo domínio de negócio: feature auth inclui tudo relacionado à autorização (formulário de login, formulário de registro, redefinição de senha); entity user inclui o modelo User, UserRepository e serialização. Os limites não devem se sobrepor: se feature auth precisa de dados do usuário — ele importa entity user em vez de duplicar a lógica. No desenvolvimento móvel, um slice FSD frequentemente corresponde a um módulo Gradle no Android ou um pacote Swift no iOS.

Os slices são estritamente isolados: a estrutura interna de um slice é invisível para outros slices. Para interação entre slices, é usada uma API pública — um arquivo index.ts/index.js que exporta apenas o que é permitido para uso externo. Todo o resto são módulos privados. Esta abordagem previne dependências acidentais e simplifica a refatoração: alterar a implementação privada de um slice não afeta outros slices.

Segmentos: UI, API, Model, Lib dentro de um slice

Dentro de cada slice FSD, o código é adicionalmente organizado por segmentos — categorias técnicas que se repetem em todos os slices. O conjunto padrão de segmentos inclui ui (componentes de interface), model (lógica de negócio, Store, Actions, Reducer), api (solicitações ao servidor, mutações), lib (utilitários e ajudantes) e config (configuração da feature).

Segmentos são uma recomendação, não uma regra estrita. Se um slice é pequeno, os segmentos podem ser combinados. Para slices grandes (uma feature com 10+ arquivos), a segmentação é obrigatória — sem ela, a estrutura interna rapidamente se torna um «cesto» de 50 arquivos onde encontrar o componente necessário leva minutos. No desenvolvimento móvel, os segmentos são frequentemente substituídos por uma estrutura de arquivos por tipo: cada feature é um arquivo Swift separado ou uma classe Kotlin com tipos internos.

FSD no desenvolvimento móvel: adaptação para Android e iOS

No desenvolvimento móvel, FSD se adapta às características específicas da plataforma — a estrutura modular do Android (módulos Gradle) e Swift Package Manager. Adaptação para Android pressupõe que cada slice é um módulo Gradle separado com seu próprio build.gradle. Os módulos feature-auth, feature-profile, entity-user, shared-ui são isolados entre si no nível de compilação: feature-auth não pode importar feature-profile a menos que especificado em dependencies.

Adaptação para iOS é construída no Swift Package Manager: cada slice é um pacote Swift com uma API pública. Em projetos TCA, o slice feature.auth contém seu próprio Reducer, Store, View e cliente API. De acordo com a Swift Community Survey 2024, 28% dos projetos iOS com TCA usam uma arquitetura de slices próxima ao FSD.

O principal problema da adaptação móvel do FSD é a duplicação da camada shared. No desenvolvimento móvel, os componentes de UI (shared/ui) frequentemente dependem da plataforma (Android Views vs Jetpack Compose vs SwiftUI), o que requer módulos shared separados para cada tecnologia. No FSD, a camada shared é geralmente independente de plataforma (utilitários, configurações), enquanto o UI-kit é movido para um módulo separado ou biblioteca de componentes.

Vantagens e desvantagens do Feature-Sliced Design

Vantagens do FSD tornam-se notáveis em projetos grandes com 10+ desenvolvedores. Cada desenvolvedor ou equipe trabalha em seu próprio slice sem tocar no código dos outros. Conflitos no git são reduzidos em 40–60% (dados de estudos de caso feature-sliced.design). Novas features são adicionadas sem risco de quebrar as existentes, desde que usem apenas a API pública dos slices. Refatorar uma feature não requer alterações em outras — basta reescrever ui/model/api dentro de um slice mantendo a API pública.

Desvantagens do FSD — aninhamento excessivo para projetos pequenos. Se uma aplicação consiste em 3–5 telas, sete camadas e segmentação dentro de cada slice criam mais código organizacional do que a própria aplicação. A barreira de entrada é alta: novos desenvolvedores gastam 2–4 semanas aprendendo a metodologia. Além disso, FSD é pouco compatível com prototipagem rápida — a prototipagem requer importações frequentes entre camadas, que são proibidas no FSD e retardam as iterações.

Recomenda-se começar com uma estrutura Feature-based mais simples e migrar para FSD quando o número de telas exceder 20 e a equipe ultrapassar 5 desenvolvedores.