# Dominio Notification

## Propósito

Orquesta notificaciones de negocio por correo a partir de eventos de otros dominios.

## Eventos atendidos

- `UserRegistered`: dispara el correo de bienvenida.
- `PasswordResetRequested`: envía el código de recuperación si el intento sigue pendiente.
- `PurchasePaid`: envía la confirmación de compra y adjunta los tickets generados, cuando corresponde.

## Componentes

Los listeners delegan en `NotificationMailService`. Este servicio carga el contexto necesario, renderiza las vistas y envía mediante `Integration/MailService`.

`IdempotentEmailDeliveryService` coordina los envíos automáticos mediante la tabla
`email_deliveries`. Cada correo utiliza una clave de negocio única:

- bienvenida: `welcome:{tenant_code}:{user_id}`;
- recuperación: `password-reset:{attempt_id}`;
- compra confirmada: `purchase-confirmed:{purchase_id}`;
- reprogramación: `event-date-rescheduled:{source_event_date_id}:{destination_event_date_id}:{purchase_id}`;
- suspensión: `event-date-suspended:{event_date_id}:{purchase_id}`.

Los correos de prueba y de validación de una integración SMTP no usan esta capa,
porque su reenvío explícito es parte de su comportamiento esperado.

## API y dependencias

No expone rutas HTTP. Consume datos de `Auth`, `Tenant`, `Purchase` y `Ticket`, y delega la entrega al dominio `Integration`.

## Consideraciones

- Los listeners reciben identificadores y vuelven a cargar los modelos, evitando transportar entidades obsoletas.
- La recuperación no se envía si el intento dejó de estar pendiente.
- Los correos de cuenta (bienvenida y recuperación de contraseña) usan la identidad visual del `WebsiteType` asociado al tenant, con fallback al tenant si no tiene uno configurado.
- El correo transaccional de compra confirmada usa la identidad visual del tenant y adjunta un único PDF cuando la compra generó tickets.
- Los handlers deben permanecer idempotentes o tolerantes a reintentos de cola.
- Una entrega queda en estado `processing` mientras un worker posee su claim. Si
  el worker se interrumpe, el claim vence según `EMAIL_DELIVERY_LEASE_SECONDS` y
  otro intento puede recuperarlo.
- Los fallos quedan registrados como `failed` y pueden ser retomados por los
  reintentos de la cola. Los envíos exitosos permanecen como `sent` y las llamadas
  posteriores con la misma clave no vuelven a enviar el correo.
- SMTP no ofrece una confirmación transaccional junto con la base de datos. Una
  interrupción ocurrida después de entregar el correo y antes de registrar
  `sent` puede producir un duplicado excepcional al recuperar el claim.