Las aplicaciones frontend crecen desordenadas si no tiene límites claros desde el inicio. Una arquitectura de características en capas permite crecer sin duplicación.
Características, no tecnología, como unidad de organización
Una característica es un dominio: autenticación, posts, usuarios, suscripciones. Cada una tiene sus componentes, hooks, servicios, tipos. Vivir juntos facilita mantener cohesión.
Esto es opuesto a agrupar por tipo: todas las componentes en /components, todos los hooks en /hooks. Eso produce dispersión.
- src/features/auth/ para autenticación.
- src/features/posts/ para posts.
- Cada feature tiene sus propios componentes, hooks, servicios.
Capas dentro de cada feature
Dentro de una feature: componentes para UI, hooks para lógica, servicios para llamadas externas, tipos para tipos, esquemas para validación.
Esa estructura da claridad: si necesitas cambiar UI, está en components. Si necesitas cambiar lógica de validación, está en schemas.
- components/: UI del feature.
- hooks/: lógica reutilizable.
- services/: llamadas a APIs.
- types/: tipos dominio.
- schemas/: validación con Zod.
Límites de acceso: una feature no importa de otra feature
Eso es la regla más importante. Un feature puede usar lib y components/shared. Pero nunca debe importar de features/<otro>. Eso previene ciclos y acoplamiento.
Si necesitas lógica compartida, va a lib. Eso fuerza decisiones de arquitectura correctas.
- feature/<a> no importa de feature/<b>.
- Lógica compartida va a lib/.
- Componentes compartidos van a components/shared/.
Indexación clara con barrel files
Un archivo index.ts en cada carpeta que exporta lo público de esa feature. Eso hace claros qué está disponible al exterior y qué es interno.
Imports se vuelven simples: en lugar de from "features/posts/hooks/usePosts", es from "features/posts".
Un índice bien hecho documenta la API pública de tu feature sin necesidad de comentarios.
Escalabilidad: cuándo refactorizar la estructura
Si un feature crece demasiado, divídela. Si compartida crece, crea sub-features. La arquitectura es flexible si necesitas cambiarla. Lo importante es que hoy sea clara.
La estructura debe servir el código, no al revés.