MAD AI está dividido en dos repositorios. El cliente Angular contiene la entrada SSR, la interfaz administrativa por rutas, capas explícitas y adaptadores HTTP. Un servicio Django REST separado concentra la aplicación y persistencia del backend. Ambos repositorios pueden evolucionar de forma independiente y se conectan mediante el contrato REST.
CASO DE ESTUDIO · ARQUITECTURA FULL-STACK
MAD AI
Una aplicación web administrativa con un cliente Angular 20 y una API privada en Django 5.2 mantenida por separado, con autenticación, gestión de usuarios y roles, notificaciones y reportes.
Código mixto Mantenido
LÍMITE DEL SISTEMA
Un cliente Angular público y una API privada mantenida por separado
PROBLEMA
Los flujos administrativos acumulan responsabilidades transversales rápidamente
Autenticación, navegación protegida, administración de usuarios, roles, notificaciones y reportes necesitan comportamiento compartido sin convertir los componentes de interfaz en clientes HTTP directos. El proyecto separa esas responsabilidades en ambos extremos: un cliente Angular con capas explícitas y un servicio Django REST con sus propios límites de aplicación, dominio e infraestructura.
SISTEMA
Dos repositorios, dos límites arquitectónicos independientes
Límite actual del sistema MAD AI El cliente Angular 20 renderiza en navegador o mediante SSR y consume una API REST Django 5.2 mantenida por separado. El backend usa DRF/JWT, soporte PostgreSQL y Celery para trabajo asíncrono.
FRONTEND
Las capas corresponden a límites reales dentro de Angular
DOMINIO
CONTRATOS ANTES QUE TRANSPORTE
Las entidades y abstracciones de repositorio definen lo que autenticación, usuarios, roles y notificaciones necesitan sin incrustar detalles de endpoints en los componentes de las rutas.
APLICACIÓN
LOS CASOS DE USO COORDINAN LA INTENCIÓN
La capa de aplicación queda entre presentación e infraestructura para que los flujos de UI expresen acciones mediante casos de uso en vez de acoplar cada componente a la mecánica HTTP.
INFRAESTRUCTURA
LOS REPOSITORIOS HTTP ADAPTAN LA API
Las implementaciones concretas de autenticación, notificaciones, roles y usuarios
encapsulan DTOs e interacción con la API detrás de contratos de repositorio. La
configuración de entorno dirige esos adaptadores a /api/v1.
PRESENTACIÓN
LAS RUTAS SEPARAN ÁREAS PÚBLICAS Y PROTEGIDAS
Las rutas de autenticación usan su propio layout; el panel y la administración de
usuarios viven detrás de AuthGuard dentro de la interfaz protegida. Angular SSR y
Express proporcionan la entrada renderizada en servidor.
BACKEND
La API usa una arquitectura Django modular y pragmática
El backend usa Django 5.2.3 y Django REST Framework 3.16.0, con JWT/cryptography, PostgreSQL mediante psycopg2, filtrado, herramientas OpenAPI y Celery. Su arquitectura combina una capa de servicios, modelos Django centrados en dominio y ports/adapters sin forzar un dominio independiente del framework que duplique el ORM.
La API se mantiene en un repositorio privado, por lo que el contrato REST funciona como límite explícito entre el cliente público y la implementación backend. Presentación e interacción permanecen del lado del cliente; la orquestación de aplicación y la persistencia quedan detrás de la API.
REPORTES
El cliente concentra visualización y exportación
El cliente Angular incluye ECharts, jsPDF y PapaParse. Mantener gráficos y exportación en el cliente permite transformar respuestas de la API en visualizaciones interactivas y archivos descargables sin trasladar responsabilidades de presentación al servicio REST.
IMPLEMENTACIÓN ACTUAL
Las responsabilidades permanecen explícitas entre cliente y API
CLIENTE
ANGULAR 20 · SSR · EXPRESS 5 · TAILWIND 4
El cliente usa Angular 20, Angular SSR, Express 5, RxJS y Tailwind CSS 4. El código
separa domain, application, infrastructure y presentation, con rutas protegidas
e implementaciones concretas de repositorios HTTP.
API
DJANGO 5.2 · DRF 3.16 · JWT · POSTGRESQL · CELERY
La API usa Django 5.2.3 y DRF 3.16 con JWT/cryptography, soporte PostgreSQL y Celery. Sigue siendo un servicio privado mantenido por separado del cliente público.
LÍMITE ACTIVO
REST REQUEST/RESPONSE ES EL TRANSPORTE ACTUAL
El backend mantenido no incluye Django Channels, por lo que WebSocket queda fuera del flujo actual del sistema. La integración entre cliente y API se concentra en el contrato REST.
LÍMITE DE ENTREGA
CLIENTE Y API PUEDEN EVOLUCIONAR POR SEPARADO
La división mantiene separadas las responsabilidades de presentación y backend. Los cambios en cualquiera de los dos lados deben preservar el contrato REST compartido sin obligar a ambos repositorios a compartir detalles de implementación.
APRENDIZAJES
Qué reforzó el diseño en dos repositorios
APRENDIZAJE 01
LA ARQUITECTURA DEL CLIENTE TAMBIÉN PUEDE TENER LÍMITES REALES
Un frontend puede separar intención de dominio de adaptadores HTTP en lugar de tratar cada componente como un wrapper directo de un endpoint.
APRENDIZAJE 02
LOS LÍMITES LIMPIOS PUEDEN SER PRAGMÁTICOS CON EL FRAMEWORK
Los modelos Django pueden seguir siendo entidades de dominio ricas mientras servicios y puertos de repositorio protegen orquestación y adaptadores externos; Clean Architecture no exige pelear contra el framework.
APRENDIZAJE 03
LOS LÍMITES DE REPOSITORIO DEBEN REFLEJAR LOS DEL SISTEMA
Mantener los contratos del cliente separados de los detalles de implementación backend reduce el acoplamiento y aclara las responsabilidades de presentación, transporte y persistencia.