Diagrama UML de Clases — Modelo de Dominio (ExpressMX)

Resumen ejecutivo

Este documento presenta el modelo de dominio de ExpressMX como un diagrama UML de clases en notación Mermaid. ExpressMX es una plataforma mexicana de servicios a domicilio que articula cuatro subdominios: catálogo y geografía, operación de órdenes, finanzas y soporte ITSM (estilo ServiceNow), todo bajo un modelo RBAC zero-trust.

A diferencia del Modelo Entidad-Relación (database-er-conceptual.md), que se enfoca en la persistencia, este diagrama muestra clases con responsabilidades (atributos + métodos de dominio), herencia entre los tres tipos de usuario, composición para los agregados raíz (orden, ticket, mayor incidente) y multiplicidades explícitas en cada asociación. Cada método del diagrama está respaldado por una server action o función SQL que ya existe en el repositorio; la sección "Trazabilidad" lo demuestra con referencias archivo:línea.

El diagrama cubre:

• 28 clases (18 mínimas requeridas + 10 adicionales para completar el dominio).
• 35 asociaciones con multiplicidades explícitas.
• 3 composiciones de agregado raíz.
• 1 jerarquía de herencia (Cliente / Prestador / Admin sobre Usuario).
• 26 métodos de dominio que reflejan reglas de negocio reales.

Diagrama (PlantUML)

Fuente: uml-class-diagram.puml

Renderizar con: plantuml -tpng uml-class-diagram.puml

2. Trazabilidad — clase a archivo fuente

Cada clase del diagrama mapea a una tabla del schema y, donde aplica, a una server action que implementa sus métodos de dominio. La columna Schema indica el origen físico de los atributos; la columna Métodos indica el archivo que materializa el comportamiento.

2.1 Métodos no implementados (marcados como pendientes)

3. Notación

Símbolos UML utilizados en este diagrama:

3.1 Decisiones de modelado

• Herencia sobre Usuario: aunque a nivel físico hay una sola tabla usuarios con discriminador rol, a nivel de dominio cada subtipo tiene comportamiento distinto. La herencia se mapea con el patrón Single Table Inheritance.
• Calificacion como entidad fuerte: en el ER conceptual aparece como asociativa ternaria (calificador × calificado × orden), pero a nivel UML se modela como clase fuerte porque tiene identidad propia y reglas de unicidad sobre (orden_id, calificador_id).
• Reembolso con dos métodos: aprobar y procesar están separados intencionalmente para reflejar la regla de Segregation of Duties (el aprobador debe ser distinto del procesador). El método rechazar cierra el ciclo cuando el reembolso no procede.
• Ticket con tipo: el campo tipo (incidente | solicitud | problema | cambio) proviene de la migración 006 ITSM y permite que la misma clase sirva para los cuatro flujos de ServiceNow sin sub-clases.

4. Cobertura del Caso Práctico

Cubre Problema 2 (Arquitectura) y Problema 3 (BD a nivel objeto) del Caso Práctico SOFTWARE 6.

• Problema 2 — Arquitectura: el diagrama materializa el modelo de dominio como capa de objetos, con composición / herencia / asociaciones; demuestra que el código del dashboard (server actions) implementa los métodos del modelo.
• Problema 3 — Base de datos a nivel objeto: la sección "Trazabilidad" prueba que cada clase corresponde a una tabla persistente del schema y que los atributos del dominio se preservan al pasar al modelo relacional. Los tipos lógicos (UUID, DateTime, JSONB, etc.) abstraen los tipos físicos de PostgreSQL para mantener el diagrama portable a otros motores.

↑ Volver arriba