refactor(backend): reorganize domains into Core, Commerce, Ticketing and Shared

app/Domains/Ticketing/Event/documentacion/README.md

@@ -0,0 +1,37 @@
+# Dominio Event
+
+## Propósito
+
+Administra la configuración temporal de un tenant orientado a eventos y sus fechas disponibles.
+
+## Componentes
+
+- `Models/EventDate.php`: fecha del evento con inicio, fin, tenant y variantes asociadas.
+- `Services/EventService.php`: obtiene y actualiza la configuración de evento del tenant.
+- `Services/EventDateNoticeService.php`: reclama y agrupa los cambios pendientes de cada usuario.
+- `Controllers/AdminApp/EventController.php`: consulta y modificación desde AdminApp.
+- `UpdateEventRequest`: valida datos y reglas cruzadas de fechas.
+- `EventResource`: serializa la configuración de salida.
+
+## Endpoints
+
+Bajo `/v1/adminapp/tenant/event`, protegidos por `auth:sanctum` y `adminapp.tenant`:
+
+- `GET`: obtiene la configuración.
+- `PUT`: actualiza la configuración.
+
+Para el storefront autenticado:
+
+- `POST /tenants/{tenant}/event-date-notices/claim`: devuelve hasta un aviso de suspensiones y otro de
+  reprogramaciones. Cada cambio se muestra como máximo tres veces por usuario.
+
+## Dependencias
+
+Depende de `Tenant`. Las fechas se vinculan con variantes de `Catalog`, que a su vez pueden generar tickets.
+
+## Consideraciones
+
+Los avisos se construyen dinámicamente después de excluir los cambios que el usuario ya vio
+tres veces. Al reclamar los avisos se incrementa una vez cada cambio incluido, aunque varios
+cambios aparezcan agrupados en el mismo mensaje. El reclamo bloquea al usuario durante la
+transacción para impedir que pestañas concurrentes superen el máximo.