Arquitectura por features: organizar una app que dura

Una app pequeña cabe en unos pocos archivos. Una app que crece necesita una ESTRUCTURA que escale: dónde va cada componente, servicio y store, para que —meses después, con más gente tocando el código— siga siendo fácil de encontrar y modificar sin romper otras cosas. La respuesta moderna es organizar por FEATURES, no por tipos de archivo. Hoy dominas esa arquitectura, la misma que aplicaste en React (SC-06 M10), adaptada a Angular.

Por proyectos, no por herramientas

Por tipo (no escala) vs por feature (escala)

❌ POR TIPO (se rompe al crecer):
src/app/
components/   → 60 componentes de todo mezclados
services/     → 40 servicios de todo mezclados
models/       → 50 interfaces mezcladas
(para tocar 'gastos' saltas entre las tres carpetas)

✅ POR FEATURE (escala):
src/app/
features/
  gastos/
    gastos-lista.component.ts
    gasto-detalle.component.ts
    bolsillo.store.ts
    api-gastos.service.ts
    gastos.routes.ts
  reportes/
    ...su propio mundo...
  perfil/
    ...
shared/     → componentes/utilidades reutilizables entre features
core/       → servicios singleton globales (auth, config, interceptores)

Con la estructura por feature, todo lo de "gastos" vive en features/gastos/: para trabajar en esa parte, abres UNA carpeta. La COLOCACIÓN (mantener juntas las cosas que cambian juntas) reduce el salto entre archivos y hace obvio dónde agregar algo nuevo.

Los tres niveles: feature, shared, core

Límites entre features

El puente con React

Si esto te suena, es porque lo viste en React (SC-06 M10): "taller por proyectos, no por herramientas". La arquitectura por features es AGNÓSTICA del framework —es una idea de organización de código que aplica igual en React, Angular, Vue o cualquier app que crezca—. Angular la favorece especialmente porque su lazy loading (loadChildren) opera naturalmente a nivel de feature, y herramientas como Nx (monorepos) imponen los límites entre features de forma automática (lo verás en el módulo de producción).

Mini-reto

Diseña la estructura de carpetas de "Mi Bolsillo" con tres features (gastos, reportes, perfil) más shared y core. Para cada uno de estos, di en qué carpeta va y por qué: 1) el BolsilloStore; 2) un AuthService; 3) un componente <app-tarjeta> genérico reutilizable; 4) el authInterceptor; 5) un pipe formatoMoneda. Marca qué feature se cargaría perezosamente.

Qué sigue

Tienes la estructura. Falta un patrón que conecta esa estructura con los componentes de forma limpia: el FACADE —una fachada que le da a los componentes una API simple sobre el store y los servicios de una feature, ocultando la complejidad interna—. La próxima lección lo cubre y cierra la teoría del módulo.