Screaming Architecture: La Clave para un Frontend Escalable

¿Qué es Screaming Architecture?

Cuando abres un proyecto, ¿sabes al instante de qué trata, o tienes que bucear en el código para entenderlo? Si tu respuesta es lo segundo, este artículo es para ti.

Te voy a contar sobre Screaming Architecture, un enfoque de organización de código que, en lugar de gritar la tecnología que usas, grita el propósito del negocio y sus funcionalidades.

¿Por qué usarlo en el frontend?

• 🧭 Claridad inmediata: entendés el propósito del código con solo ver la estructura.
• 🧱 Escalabilidad real: cada funcionalidad crece de forma aislada y ordenada.
• 👥 Onboarding más rápido: nuevos devs entienden mejor y más rápido el proyecto.
• 🧹 Refactorizaciones más seguras: todo está más encapsulado.
• 🚀 Facilita pruebas, modularización y división de equipo.

El Problema de la Estructura "Genérica"

La mayoría de los proyectos frontend, especialmente al inicio, usan una estructura de carpetas basada en tipos técnicos: components/, views/, services/, utils/, store/, etc.

src/
├── components/
├── views/
├── services/
├── utils/
└── store/
└── ...

Si bien es un punto de partida, esta estructura tiene sus problemas, especialmente a medida que tu aplicación crece:

• Dispersión de la lógica: Para una sola funcionalidad (ej. "Gestión de Usuarios"), sus partes (componentes de UI, lógica del store, llamadas a la API) están esparcidas por todo el proyecto.

• Dificultad de navegación: Tienes que saltar entre muchas carpetas para entender cómo funciona una característica completa.

• Mantenimiento doloroso: Un cambio en una función puede requerir modificar archivos en varias carpetas, aumentando el riesgo de introducir errores.

• Acoplamiento a la infraestructura: La estructura te dice cómo está hecho (con servicios, componentes), no qué hace tu negocio.

Imagina el plano de una casa. No ves una sección de "ladrillos", otra de "cemento" y otra de "ventanas". Ves "cocina", "dormitorio", "baño". Los planos "gritan" el propósito y las funciones de cada espacio.

La Screaming Architecture busca lo mismo para tu código. Tu estructura de carpetas de alto nivel debería "gritar" las características principales o los dominios de negocio de tu aplicación, no las tecnologías que usas.

Ventajas de usar Screaming Architecture

Implementar este enfoque no es solo por estética, trae beneficios tangibles que te permiten escalar tu aplicación y tu equipo.

• Entendimiento instantáneo: Abres el proyecto y de un vistazo sabes que hace el negocio.

• Onboarding veloz: Nuevos desarrolladores entienden la estructura del negocio mucho más rápido.

• Mantenimiento simplificado: Los cambios en una funcionalidad se mantienen localizados en su propio módulo.

• Cambios aislados, menos errores: Reduces el riesgo de romper otras partes del sistema al modificar una feature.

• Código más escalable: Puedes añadir nuevas funcionalidades (features) sin afectar el código de las existentes.

• Navegación intuitiva: Buscas funcionalidades de negocio, no tipos de archivos genéricos.

• Menos acoplamiento: La lógica de negocio central es más independiente de los detalles técnicos.

• Refactorización más segura: Mover o refactorizar una feature entera es menos arriesgado.

• Facilita el testing: Las funcionalidades son más fáciles de aislar y testear.

• Tu proyecto se vuelve predecible: El crecimiento es organizado y controlado.

Aplicando Screaming Architecture

Tomaremos como ejemplo un proyecto de Vue, pero es 100% aplicable a cualquier otra tecnología.

La clave es agrupar el código por features o dominios de negocio. Cada carpeta de feature contendrá todo lo necesario para esa funcionalidad.

Aquí tienes un ejemplo práctico de cómo podría verse la estructura en tú proyecto:

src/
├── modules/              # También podría llamarse "Features" o "Domain", algo que agrupe
│   │                       las funcionalidades
│   ├── Auth/             # Todo lo relacionado con autenticación
│   │   ├── components/   # LoginButton.vue, RegisterForm.vue
│   │   ├── views/        # LoginView.vue, RegisterView.vue
│   │   ├── routes/       # Rutas específicas de este módulo
│   │   ├── store/        # auth.store.js (store de Pinia para Auth)
│   │   └── services/     # auth.service.js (llamadas a la API de Auth)
│   ├── Products/         # Todo lo relacionado con productos
│   │   ├── components/   # ProductCard.vue, ProductList.vue
│   │   ├── views/        # ProductsView.vue, ProductDetailView.vue
│   │   ├── routes/       # Rutas específicas de este módulo
│   │   ├── store/        # products.store.js
│   │   └── services/     # products.service.js
│   ├── Orders/           # Todo lo relacionado con pedidos
│   │   ├── components/
│   │   ├── routes/
│   │   ├── views/
│   │   ├── store/
│   │   └── services/
│   └── Profile/          # Y así sucesivamente para otras features...
│       ├── components/
│       └── ...
├── shared/               # Elementos verdaderamente transversales que no pertenecen a una
│   │                       feature específica
│   ├── ui/
│   │   ├── components/   # BaseButton.vue, ModalBase.vue (componentes UI genéricos)
│   │   └── composables/  # useModal.js, useDarkMode,js (composables que afectan sólo a
│   │                       componentes de UI)
│   ├── composables/      # useDebounce.js, useLocalStorage.js (lógica reutilizable
│   │                       sin estado de negocio)
│   ├── utils/            # formatDate.js, validateEmail.js
│   └── assets/           # Imágenes globales, estilos base
├── layouts/              # Plantillas de layout (DefaultLayout.vue, AuthLayout.vue)
├── router/               # Router general de la aplicación
├── app.vue
├── main.js
└── vite.config.js        # Configuración de vite

La estructura mencionada es sólo un ejemplo, puedes adaptarla según tus propias necesidades.

Lo importante es que cada Module tenga su propia estructura de carpetas según lo necesites, no siempre vas a tener un "Store" o "Services" en cada módulo, por ejemplo.

¿Cuándo Usar Screaming Architecture? (¿y cuándo no?)

Este enfoque es poderoso, pero no es la bala de plata para todos los proyectos:

Ideal para:

• Proyectos medianos a grandes con lógica de negocio compleja.
• Aplicaciones que se espera que crezcan significativamente.
• Equipos con varios desarrolladores.
• Cuando la claridad y el mantenimiento a largo plazo son prioritarios.

Quizás excesivo para:

• Proyectos muy pequeños o MVPs ("Minimum Viable Products") que sabes que no escalarán mucho.
• Aplicaciones CRUD (Crear, Leer, Actualizar, Borrar) muy simples donde la lógica es mínima.

Consideraciones:

• Si tu proyecto tiene potencial de crecer, adoptar la Screaming Architecture desde el principio o al menos en fases tempranas, te ahorrará muchos dolores de cabeza en el futuro.
• En una aplicación existente, puedes ir adoptando Screaming Architecture de forma progesiva, migrando un módulo a la vez.

Conclusión: Haz que tu Arquitectura Grite su Propósito

La Screaming Architecture es más que una simple forma de organizar carpetas; es una mentalidad que prioriza la cohesión del negocio sobre la infraestructura técnica. Al hacer que tu código grite sus funcionalidades, no solo mejoras la legibilidad y la mantenibilidad, sino que defines una base sólida para que tu frontend escale de forma eficiente y controlada.

¿Estás listo para que la arquitectura de tu próximo proyecto comience a gritar?