# Backoffice Commizzion ### 📃 Contexto General El proyecto **Backoffice Commizzion** (anteriormente conocido como "Adviser") representa la plataforma administrativa del ecosistema Commizzion. Su propósito es brindar herramientas a los usuarios de tipo administrador, ejecutivo, gestor comercial o soporte, para gestionar campañas, afiliados, acuerdos, pagos, seguimiento de KPIs, análisis de desempeño y manejo de reportes globales. La versión anterior del backoffice estaba construida con **Angular 15**, en un estado aún más crítico que el frontend de Account. La ausencia de arquitectura clara, patrones inconsistentes y la carencia de un sistema de diseño unificado generaban una enorme deuda técnica que afectaba directamente la productividad, la estabilidad del sistema y la experiencia del usuario interno. *** ### ❌ Problemas del Sistema Anterior * **Monolito Angular mal estructurado**: el proyecto creció sin planificación ni separación de dominios. * **Falta total de arquitectura modular**: no existían capas de presentación, negocio y acceso a datos bien definidas. * **Altamente acoplado y frágil**: cualquier cambio afectaba otras partes inesperadas del sistema. * **Falta de pruebas y control de errores**: la mayoría del código era propenso a fallos y difícil de mantener. * **UI inconsistente**: sin una librería de componentes común, con estilos repetidos, divergentes y no escalables. * **Mala experiencia de usuario**: tiempos de carga extensos, navegación poco intuitiva y formularios sin validación. * **Backend (api-admin-commizzion)** sin separación por dominios ni control de acceso granular. Lógica de negocio mezclada y endpoints acoplados. *** ### 🚀 Decisión de Reconstrucción Dado el éxito técnico y organizacional del nuevo frontend de Account Commizzion y su entorno tecnológico, se decidió reconstruir el **Backoffice Commizzion** con la misma base de tecnologías modernas: * React + Next.js * Zustand para estado global * React Query para manejo de datos * UI Kit compartido (`libs-ui-kit-inlaze`) * Arquitectura modular orientada a dominio Esto permite mantener **alineación tecnológica y de diseño entre equipos**, reducir curva de aprendizaje, compartir componentes y patrones, y facilitar el mantenimiento transversal del producto. *** ### ✨ Stack Tecnológico Actual * **Framework**: React 18 + Next.js (App Router) * **State Management**: Zustand (por dominio: afiliados, campañas, pagos, etc.) * **Data Fetching**: React Query + Middlewares de manejo de errores y autorización. * **UI Kit**: libs-ui-kit-inlaze con tokens de diseño definidos en Figma. * **Routing y estructura modular**: cada módulo como feature independiente: `/affiliates`, `/campaigns`, `/agreements`, etc. * **Testing**: Jest + Playwright + utilidades de testeo de hooks y stores. * **Soporte para roles y permisos**: control granular por tipo de usuario. *** ### 📂 API: Consolidación en `api-commizzion` La antigua `api-admin-commizzion` se reemplaza y centraliza dentro de la nueva API NestJS `api-commizzion`. Esta contiene: * **Módulo `admin`**: exclusivo para operaciones del backoffice. * Secciones como campañas, usuarios, gestión de acuerdos, pagos, configuraciones, entre otras. * **Control de acceso** granular: guards, interceptors, políticas. * **Arquitectura modular y desacoplada**: separación por bounded contexts. * **Reutilización de lógica compartida con `client`** donde aplica. Esto permite una expansión ordenada, mantenible, documentada y con integración directa hacia sistemas externos si es necesario (ej. CRM, contabilidad, motores de análisis). *** ### 🛠 Estado del Proyecto * El nuevo backoffice está en **fase de desarrollo activo**. * Se han priorizado los módulos más críticos: campañas, afiliados, reportes y acuerdos. * Algunos módulos antiguos aún consumen la `api-admin-commizzion`, pero se encuentran en proceso de migración progresiva. * Se han establecido estándares de diseño, arquitectura, pruebas y documentación que deben seguirse en cada nuevo módulo. * Existe un esfuerzo paralelo de refactor progresivo para evitar interrupciones a los usuarios actuales. *** ### 📈 Beneficios Esperados * **Homogeneidad en la experiencia de usuario** con el resto del ecosistema Commizzion. * **Mayor productividad para el equipo de desarrollo**: entorno estable, reutilizable y predecible. * **Facilidad de incorporación de nuevos colaboradores**: documentación clara, patrones definidos y entorno estándar. * **Reducción del riesgo de fallos**: mayor control de errores, validaciones, tipado estricto y pruebas automatizadas. * **Escalabilidad futura asegurada**: módulos nuevos pueden ser agregados de forma independiente. *** ### 🔚 Conclusión La reescritura del Backoffice Commizzion no solo era necesaria, sino fundamental para el crecimiento sostenible del producto y la organización. Su implementación con un stack moderno, arquitectura modular, UI unificada y backend desacoplado garantiza una plataforma administrativa robusta, segura y preparada para soportar las operaciones y necesidades futuras de la empresa. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs-affiliates.inlaze.com/justificaciones-tecnicas/backoffice-commizzion.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.