Vertical Slicing vs Feature-Sliced Design: cuál es la diferencia y cuándo usar cada una

Vertical Slicing y Feature-Sliced Design se parecen mucho a primera vista. Las dos ideas empujan en la misma dirección: dejar de organizar frontend por tipo técnico y empezar a organizarlo por intención de producto.

Pero no son lo mismo.

La diferencia corta es esta: Vertical Slicing es una idea arquitectónica; Feature-Sliced Design es una metodología más formal.

Vertical Slicing te dice: agrupa lo que cambia junto.

Feature-Sliced Design te dice: agrupa por intención, pero además respeta capas, reglas de dependencia, public APIs y responsabilidades más estrictas.

Este post compara ambas arquitecturas para que no las mezcles sin darte cuenta y, sobre todo, para que elijas con criterio.

---

El problema que ambas intentan resolver

La estructura clásica de frontend suele empezar así:

src/
├── components/
├── hooks/
├── services/
├── utils/
├── types/
└── pages/

Se ve ordenada, pero organiza el proyecto por tipo de archivo, no por motivo de cambio.

Si quieres modificar checkout, probablemente tengas que abrir:

• Un componente en components.
• Un hook en hooks.
• Una llamada HTTP en services.
• Un tipo en types.
• Una función en utils.
• Una pantalla en pages.

Eso no es arquitectura. Eso es una búsqueda del tesoro.

Vertical Slicing y Feature-Sliced Design nacen para resolver ese problema: hacer que el código se parezca más al producto y menos a una taxonomía técnica.

---

Qué propone Vertical Slicing

Vertical Slicing propone organizar el código por funcionalidades completas.

En vez de separar primero por components, hooks, services y types, agrupas todo lo necesario para una feature.

src/
├── app/
├── pages/
├── features/
│   ├── auth/
│   │   ├── api/
│   │   ├── model/
│   │   ├── ui/
│   │   └── index.ts
│   └── products/
│       ├── api/
│       ├── model/
│       ├── ui/
│       └── index.ts
└── shared/

La idea central es simple: si cambia una funcionalidad, quieres tocar archivos que viven cerca.

Eso tiene muchísimo valor.

Cuando alguien pregunta “¿dónde está el login?”, la respuesta es features/auth. No tienes que reconstruir la feature mentalmente entre seis carpetas.

Vertical Slicing es ideal cuando estás empezando a ordenar una app que ya tiene flujos claros, pero todavía no necesita reglas arquitectónicas demasiado pesadas.

---

Qué propone Feature-Sliced Design

Feature-Sliced Design toma una idea parecida, pero la formaliza más.

La estructura típica es:

src/
├── app/
├── pages/
├── widgets/
├── features/
├── entities/
└── shared/

Acá no todo vive dentro de features.

FSD separa por capas:

• app inicializa la aplicación.
• pages compone pantallas.
• widgets arma bloques grandes de interfaz.
• features modela acciones de usuario.
• entities modela conceptos del negocio.
• shared contiene infraestructura genérica.

La diferencia importante es que FSD no solo agrupa código. También define quién puede depender de quién.

Una regla práctica:

app → pages → widgets → features → entities → shared

Una capa puede importar de capas inferiores. No debería importar de capas superiores.

Eso reduce acoplamiento.

---

La diferencia en una frase

Vertical Slicing pregunta:

¿Qué archivos cambian juntos cuando cambia esta funcionalidad?

Feature-Sliced Design pregunta:

¿Qué responsabilidad tiene esta pieza dentro del producto y desde qué capa debería poder usarse?

Esa diferencia parece sutil, pero cambia mucho el diseño.

Vertical Slicing agrupa por funcionalidad.

FSD agrupa por funcionalidad y por nivel de responsabilidad.

---

Ejemplo con checkout

Imagina que tienes un flujo de checkout.

Con Vertical Slicing, podrías crear esto:

src/features/checkout/
├── api/
│   └── createOrder.ts
├── model/
│   └── types.ts
├── ui/
│   ├── CheckoutForm.tsx
│   ├── CartSummary.tsx
│   └── PaymentMethodSelector.tsx
└── index.ts

Esto es bastante mejor que tener cada archivo repartido en carpetas globales.

Pero con el tiempo checkout puede empezar a juntar demasiadas cosas:

• Carrito.
• Productos.
• Órdenes.
• Cupón.
• Pago.
• Dirección.
• Resumen.
• Confirmación.

Ahí una sola feature empieza a parecer una mini-app.

Con Feature-Sliced Design, podrías separar mejor la intención:

src/
├── pages/
│   └── checkout/
│       └── CheckoutPage.tsx
├── widgets/
│   └── checkout-summary/
│       └── index.ts
├── features/
│   ├── place-order/
│   ├── apply-coupon/
│   └── select-payment-method/
├── entities/
│   ├── cart/
│   ├── order/
│   ├── product/
│   └── payment-method/
└── shared/

La diferencia no es que FSD tenga más carpetas porque sí.

La diferencia es que cada pieza tiene una responsabilidad más precisa.

cart es una entidad.

apply-coupon es una acción.

checkout-summary es un bloque visual compuesto.

CheckoutPage es la pantalla.

Eso hace que el sistema sea más fácil de cambiar cuando crece.

---

Comparación directa

Criterio	Vertical Slicing	Feature-Sliced Design
Idea principal	Organizar por funcionalidad	Organizar por capas, slices y responsabilidad
Nivel de formalidad	Bajo a medio	Medio a alto
Curva de aprendizaje	Más simple	Más exigente
Reglas de importación	Opcionales o livianas	Parte central del diseño
Mejor para	Apps medianas o equipos que empiezan a ordenar	Apps en crecimiento con dominio más complejo
Riesgo	Features gigantes	Sobrediseño si lo aplicas demasiado pronto
Beneficio principal	Código cerca del motivo de cambio	Límites claros entre entidades, acciones y composición

La tabla importa, pero no la conviertas en religión.

La decisión depende del tamaño del producto, del equipo y del nivel de presión arquitectónica.

---

Cuándo elegir Vertical Slicing

Elige Vertical Slicing cuando quieres mejorar una app que está organizada por tipo técnico y necesitas una estructura más clara sin meter demasiada ceremonia.

Funciona muy bien si tienes flujos como:

• Login.
• Productos.
• Búsqueda.
• Favoritos.
• Perfil.
• Dashboard.

Y quieres que cada flujo tenga cerca su UI, API, tipos, estado y lógica.

También es una gran opción cuando el equipo todavía está madurando arquitectónicamente. Es más fácil de explicar, más fácil de adoptar y más difícil de sobrediseñar.

La regla práctica:

Si tu problema principal es que una feature está repartida por toda la app, empieza con Vertical Slicing.

---

Cuándo elegir Feature-Sliced Design

Elige Feature-Sliced Design cuando el problema ya no es solo dispersión, sino acoplamiento.

Señales claras:

• Las features empiezan a crecer demasiado.
• Varias features comparten entidades de negocio.
• Las páginas tienen demasiada lógica.
• shared se está llenando de código que sí tiene contexto de negocio.
• Los imports cruzados empiezan a ser difíciles de razonar.
• El equipo discute seguido dónde debería vivir una pieza.

FSD ayuda cuando necesitas reglas más fuertes para que la app no dependa de la memoria tribal del equipo.

La regla práctica:

Si tu problema principal es que las funcionalidades ya están agrupadas pero los límites son ambiguos, evoluciona hacia FSD.

---

Cuándo no usar ninguna de las dos de forma completa

No todo proyecto necesita arquitectura pesada.

Si estás haciendo una landing page, una demo pequeña o un prototipo que puede cambiar mañana, no necesitas seis capas ni una estructura perfecta.

Puedes tener algo simple:

src/
├── components/
├── pages/
└── lib/

Y está bien.

El problema no es usar una estructura simple. El problema es negar que dejó de ser suficiente cuando el producto crece.

Arquitectura prematura es mala. Pero falta de arquitectura cuando ya hay complejidad real también es mala.

La madurez está en saber cuándo cambiar de marcha.

---

Cómo evolucionar de Vertical Slicing a FSD

No tienes que migrar todo de golpe.

Puedes evolucionar en pasos.

Primero, aplica Vertical Slicing:

src/features/
├── auth/
├── products/
└── checkout/

Después observa qué empieza a repetirse o crecer.

Si features/checkout empieza a contener carrito, órdenes, productos y pagos, separa entidades:

src/entities/
├── cart/
├── order/
├── product/
└── payment-method/

Si una pantalla empieza a componer muchas piezas, crea widgets:

src/widgets/
├── checkout-summary/
└── product-catalog/

Si una feature es una acción concreta, nómbrala como acción:

src/features/
├── apply-coupon/
├── place-order/
└── select-payment-method/

Así migras con criterio. No por moda.

---

El error común: copiar carpetas sin entender límites

El peor uso de FSD es crear esta estructura:

app/
pages/
widgets/
features/
entities/
shared/

Y después importar cualquier cosa desde cualquier lugar.

Eso no es FSD. Eso es una escenografía.

También pasa con Vertical Slicing: creas features, pero cada feature importa archivos internos de otras features, mete todo en shared y termina acoplada igual.

La arquitectura no está en la carpeta. Está en las reglas que el equipo respeta.

Sin reglas, cualquier estructura se pudre.

---

Mi recomendación práctica

Si estás empezando una app mediana o estás ordenando un frontend desprolijo, empieza por Vertical Slicing.

Es simple, claro y te obliga a pensar en funcionalidades reales.

Cuando el proyecto crezca y empieces a notar entidades compartidas, widgets repetidos, páginas pesadas y reglas de importación confusas, evoluciona hacia Feature-Sliced Design.

No lo hagas al revés.

No empieces con la ceremonia completa si todavía no tienes el problema. Pero tampoco te quedes en una estructura liviana cuando el producto ya pide límites más fuertes.

Ese es el criterio senior: no elegir la arquitectura más de moda, sino la que reduce mejor el riesgo actual.

---

Cierre

Vertical Slicing y Feature-Sliced Design no compiten. Se complementan.

Vertical Slicing te enseña a dejar de pensar en carpetas técnicas y empezar a pensar en funcionalidades.

Feature-Sliced Design toma esa base y le agrega capas, reglas y límites más claros para productos que ya tienen más complejidad.

Si tu app está dispersa, usa Vertical Slicing.

Si tu app ya está agrupada pero los límites se volvieron borrosos, usa Feature-Sliced Design.

Y si tu app todavía es chica, no finjas que estás construyendo Netflix. Empieza simple, observa dónde duele y agrega arquitectura cuando el dolor sea real.

Eso es diseñar con criterio: no más carpetas por moda, no menos arquitectura por comodidad.