Feature-Sliced Design: esencia y metodología de división por features

¿Qué es Feature-Sliced Design?

Feature-Sliced Design (FSD) es una metodología de arquitectura de aplicaciones frontend propuesta por primera vez en 2021 por la comunidad feature-sliced.design. La idea central de FSD es agrupar el código por funcionalidades de negocio (slices), cada una de las cuales es una unidad autónoma: contiene su propia lógica de negocio, interfaz de usuario, interacción con API, modelos de datos y pruebas. Esto diferencia a FSD de la arquitectura clásica en capas donde el código se divide por criterios técnicos (controller, service, repository).

La metodología toma prestados conceptos de Domain-Driven Design (DDD) y Bounded Context: cada feature de la aplicación es un bounded context separado con límites claros. Los cambios dentro de una feature no deben romper otras features si solo usan la API pública del slice. Según la encuesta State of Frontend 2024, FSD ocupa el segundo lugar en popularidad entre las arquitecturas React (23%), solo detrás de la estructura informal Feature-based (31%).

En el desarrollo móvil, FSD se adapta a las particularidades de los módulos Android y los frameworks iOS. En IT Sectr, usamos FSD para proyectos con 10+ pantallas y 3+ equipos — la metodología permite desarrollar features de forma independiente y reduce los conflictos en git en un 40% en comparación con un monorrepositorio sin límites de slices.

Siete capas de FSD: estructura y reglas de importación

FSD define siete capas jerárquicas, cada una contiene código de un cierto nivel de abstracción. La regla arquitectónica principal es que las capas solo pueden importar código de capas inferiores. Violar esta regla (importar la capa features en entities) se considera un error arquitectónico y es bloqueado por un linter.

Ejemplo de estructura de directorios de un proyecto FSD:

src/
├── app/                    // Capa de aplicación
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Páginas — composición de features
│   └── main/
├── features/                // Features — escenarios de usuario
│   ├── auth/                // Slice «Autenticación»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Lista de productos»
│       ├── ui/
│       └── model/
├── entities/                // Entidades de negocio
│   ├── user/
│   └── product/
├── widgets/                 // Componentes compuestos
│   └── header/
└── shared/                  // Utilidades compartidas y UI-kit
    └── ui/

La regla «las capas miran solo hacia abajo» es la piedra angular de FSD. Si feature auth importa entity user — es correcto. Si entity user comienza a importar feature auth — es una dependencia cíclica y una violación del aislamiento. Para garantizar esta regla se utilizan plugins de ESLint (eslint-plugin-fsd) o linters personalizados de la API pública de los slices.

Slices: límites de los dominios de negocio

Slice — la unidad principal de agrupación en FSD, correspondiente a una feature o entidad de negocio. Cada slice reside dentro de una de las siete capas (features, entities, widgets, pages) y contiene un conjunto completo de código para implementar una funcionalidad específica: componentes UI, modelo de datos, cliente API, constantes y pruebas.

Los límites de los slices se definen por el dominio de negocio: feature auth incluye todo lo relacionado con la autorización (formulario de inicio de sesión, formulario de registro, restablecimiento de contraseña); entity user incluye el modelo User, UserRepository y serialización. Los límites no deben superponerse: si feature auth necesita datos de usuario — importa entity user en lugar de duplicar la lógica. En el desarrollo móvil, un slice FSD a menudo corresponde a un módulo Gradle en Android o un paquete Swift en iOS.

Los slices están estrictamente aislados: la estructura interna de un slice es invisible para otros slices. Para la interacción entre slices se utiliza una API pública — un archivo index.ts/index.js que exporta solo lo que está permitido para uso externo. Todo lo demás son módulos privados. Este enfoque previene dependencias accidentales y simplifica la refactorización: cambiar la implementación privada de un slice no afecta a otros slices.

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

Dentro de cada slice de FSD, el código se organiza adicionalmente por segmentos — categorías técnicas que se repiten en todos los slices. El conjunto estándar de segmentos incluye ui (componentes de interfaz), model (lógica de negocio, Store, Actions, Reducer), api (solicitudes al servidor, mutaciones), lib (utilidades y ayudantes) y config (configuración de la feature).

Los segmentos son una recomendación, no una regla estricta. Si un slice es pequeño, los segmentos pueden combinarse. Para slices grandes (una feature con 10+ archivos), la segmentación es obligatoria — sin ella, la estructura interna se convierte rápidamente en una «canasta» de 50 archivos donde encontrar el componente necesario lleva minutos. En el desarrollo móvil, los segmentos a menudo se reemplazan por una estructura de archivos por tipo: cada feature es un archivo Swift separado o una clase Kotlin con tipos internos.

FSD en desarrollo móvil: adaptación para Android e iOS

En el desarrollo móvil, FSD se adapta a las características específicas de la plataforma — la estructura modular de Android (módulos Gradle) y Swift Package Manager. Adaptación para Android supone que cada slice es un módulo Gradle separado con su propio build.gradle. Los módulos feature-auth, feature-profile, entity-user, shared-ui están aislados entre sí a nivel de compilación: feature-auth no puede importar feature-profile a menos que se especifique en dependencies.

Adaptación para iOS se basa en Swift Package Manager: cada slice es un paquete Swift con una API pública. En proyectos TCA, el slice feature.auth contiene su propio Reducer, Store, View y cliente API. Según la Swift Community Survey 2024, el 28% de los proyectos iOS con TCA usan una arquitectura de slices cercana a FSD.

El principal problema de la adaptación móvil de FSD es la duplicación de la capa shared. En el desarrollo móvil, los componentes UI (shared/ui) a menudo dependen de la plataforma (Android Views vs Jetpack Compose vs SwiftUI), lo que requiere módulos shared separados para cada tecnología. En FSD, la capa shared suele ser independiente de la plataforma (utilidades, configuraciones), mientras que el UI-kit se traslada a un módulo separado o biblioteca de componentes.

Ventajas y desventajas de Feature-Sliced Design

Ventajas de FSD se hacen notables en proyectos grandes con 10+ desarrolladores. Cada desarrollador o equipo trabaja en su propio slice sin tocar el código de otros. Los conflictos en git se reducen en un 40–60% (datos de estudios de caso de feature-sliced.design). Las nuevas features se añaden sin riesgo de romper las existentes, siempre que solo usen la API pública de los slices. Refactorizar una feature no requiere cambios en otras — basta con reescribir ui/model/api dentro de un slice manteniendo la API pública.

Desventajas de FSD — anidación excesiva para proyectos pequeños. Si una aplicación consta de 3–5 pantallas, siete capas y segmentación dentro de cada slice crean más código organizativo que la propia aplicación. La barrera de entrada es alta: los nuevos desarrolladores tardan de 2 a 4 semanas en aprender la metodología. Además, FSD es poco compatible con la creación rápida de prototipos — el prototipado requiere importaciones frecuentes entre capas, que en FSD están prohibidas y ralentizan las iteraciones.

Se recomienda comenzar con una estructura Feature-based más simple y migrar a FSD cuando el número de pantallas supere las 20 y el equipo supere los 5 desarrolladores.