# Account Commizzion

### 📃 Contexto General

El proyecto **Account Commizzion** representa el nuevo portal de usuarios afiliados de la plataforma Commizzion. Este frontend está pensado para que afiliados puedan consultar y gestionar sus KPIs, reportes, comisiones, referidos, actividad histórica, pagos y otros elementos relacionados a su actividad dentro del ecosistema de marketing de afiliación.

El sistema anterior, llamado **Partner Betenlace**, estaba desarrollado con **Angular 15** dentro de un **monorepo (front-commizzion)**, que incluía múltiples proyectos y configuraciones mezcladas. La estructura interna del monorepo era inconsistente, presentando mezcla de patrones, estilos y convenciones sin un criterio uniforme. Este enfoque trajo serios problemas de escalabilidad, mantenimiento y extensión funcional, lo cual dificultaba la evolución del sistema.

***

### ❌ Problemas del Sistema Anterior

* **Uso de Angular 15 en un monorepo sin arquitectura unificada**: coexistencia de múltiples enfoques que dificultaban el onboarding y el mantenimiento.
* **Arquitectura rígida y acoplada**: agregar nuevas funcionalidades requería refactorizaciones profundas o duplicación de lógica.
* **Baja mantenibilidad**: abundancia de código con soluciones “a pedal”, sin aplicar principios SOLID ni reutilización efectiva.
* **Ausencia de una librería UI común**: cada pantalla implementaba sus propios estilos y componentes desde cero.
* **Débil control de errores y validaciones inconsistentes**: afectando la experiencia del usuario.
* **API `api-affiliates` ineficiente**: la estructura venía heredada de una migración anterior, sin diseño orientado a dominio ni separación clara de responsabilidades.
* **Dificultades en testing**: pocos componentes tenían pruebas automatizadas o eran difícilmente testeables.

***

### 🚀 Decisión de Replanteamiento

En el marco del proyecto de landings corporativas para Commizzion, se exploró el uso de **React + Next.js** como alternativa moderna para frontends. A partir del éxito de esta iniciativa, y del buen rendimiento del equipo usando ese stack, se optó por reescribir completamente el frontend de Account Commizzion, adoptando un enfoque escalable y centrado en experiencia de usuario.

La decisión también estuvo respaldada por la necesidad de establecer una base tecnológica común entre todos los productos nuevos, asegurando coherencia entre iniciativas como el nuevo Backoffice.

***

### ✨ Stack Tecnológico Actual

* **Framework**: \[React 18 + Next.js (App Router)]
* **Gestión de estado global**: \[Zustand], con slices por dominio funcional.
* **Cliente de datos**: \[React Query], con caché, refetch y control granular.
* **Middlewares personalizados**: para manejo de auth, headers, errores.
* **UI Kit**: `libs-ui-kit-inlaze` — biblioteca propia de componentes, basada en Figma y manteniendo tokens de diseño reutilizables.
* **Linter + Husky + Prettier**: asegurando calidad de código continua.
* **Testing**: soporte para pruebas unitarias con Jest y pruebas e2e con Playwright.
* **Autenticación y seguridad**:
  * Login federado con Azure AD via OAuth 2.0.
  * Roles y permisos definidos por contexto (afiliado, subafiliado, gestor).

***

### 🔧 Ventajas del Nuevo Enfoque

* Arquitectura basada en **rutas desacopladas por dominio** (ej. `/dashboard`, `/referrals`, `/commissions`).
* Componentes reutilizables con composición declarativa.
* Adopción de **Atomic Design** para estructura del UI Kit.
* Mayor control sobre el rendimiento gracias a lazy loading por ruta y optimización en tiempo de compilación.
* Estandarización de patrones de diseño y estructura de carpetas (pages, features, shared, hooks).
* Mejoras visibles en **mantenibilidad, performance, accesibilidad** y tiempo de desarrollo.
* Documentación viva del sistema (README, estructura, convenciones) para facilitar onboarding de nuevos desarrolladores.

***

### 📂 Backend Unificado

Se reemplaza la antigua `api-affiliates` por una nueva API moderna y modular: **`api-commizzion`**, estructurada con **NestJS** y orientada a dominio, permitiendo mantener un código escalable, limpio y desacoplado.

Esta API está dividida en:

* **Módulo `client`**: enfocado en operaciones para el usuario afiliado.
* **Módulo `admin`**: utilizado por el equipo de gestión y soporte desde el Backoffice.

Ambos módulos cuentan con:

* Guards y policies por rol.
* Interceptors para logging, errores y validación de sesión.
* DTOs, entities y servicios separados por bounded context.
* Soporte para internacionalización (i18n) y validaciones robustas.

Esta nueva arquitectura también simplifica el versionado y la extensión futura del sistema, permitiendo crecer sin impacto en módulos existentes.

***

### 🚧 Conclusión

La reestructuración de Account Commizzion fue una decisión técnica estratégica, guiada por la necesidad de modernizar el stack, mejorar la mantenibilidad y escalar la funcionalidad de forma segura y sostenible.

Gracias a la adopción de Next.js, una arquitectura orientada a dominios, un UI kit propio y una API unificada y modular, se ha establecido un ecosistema más sólido, predecible y escalable. Esta base ahora permite que el producto crezca más rápido, con menos deuda técnica y una mejor experiencia para los usuarios y desarrolladores por igual


---

# 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/account-commizzion.md?ask=<question>
```

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.
