El diagrama de clases de dominio representa el **modelo conceptual del negocio**: los conceptos que existen en el mundo de las agencias de viaje y las reglas que los gobiernan, sin ninguna referencia a bases de datos, framework ni HTTP. Es distinto del diagrama de clases de diseño y del modelo entidad-relación, y esa diferencia es deliberada. El modelo de datos describe cómo se guarda la información; el diagrama de diseño describe cómo se organiza el código; este describe **qué es el negocio**. Las tres vistas coinciden en muchos nombres, pero no son la misma cosa: aquí no hay claves foráneas, no hay repositorios y no hay identificadores autoincrementales como concepto central. Las clases marcadas como objeto de valor no tienen identidad propia: dos importes de mil pesos son el mismo importe. Las entidades sí la tienen: dos paquetes con los mismos datos siguen siendo dos paquetes distintos. ## Núcleo de identidad Este bloque es el que sostiene el control de acceso de todo el sistema. ```mermaid classDiagram direction LR class Usuario { -int id -string nombre -string apellido -Email email -string hashContrasena -EstadoCuenta estado -int intentosFallidos -DateTime bloqueadoHasta -DateTime ultimoAccesoEn +nombreCompleto() string +roles() Rol[] +permisos() string[] +tieneRol(nombre) bool +puede(clavePermiso) bool +estaBloqueado(ahora) bool +exigirQuePuedaIniciarSesion(ahora) +registrarAccesoExitoso(ahora) +registrarAccesoFallido(bloquearHasta) +bloquearPorAdministracion() +habilitar() +asignarRol(rol) } class Rol { +string nombre +string descripcion +otorga(clavePermiso) bool +clavesDePermisos() string[] } class Permiso { +string clave +string descripcion +equivaleA(otro) bool } class Email { <> +string valor +dominio() string +equivaleA(otro) bool } class ContrasenaPlana { <> +revelar() string +longitud() int +contiene(patron) bool } class EstadoCuenta { <> Activo Bloqueado +permiteIniciarSesion() bool } class PoliticaContrasenas { <> +requisitos() RequisitoContrasena[] +esValida(contrasena) bool +requisitosIncumplidos(contrasena) RequisitoContrasena[] +mensajeDeIncumplimiento(contrasena) string } class PoliticaBloqueoCuenta { <> -int maxIntentos -int minutosDeBloqueo +registrarFallo(usuario, ahora) +intentosRestantes(usuario) int } class RequisitoContrasena { <> +string clave +string descripcion +loCumple(contrasena) bool } Usuario "1" o-- "1..*" Rol : posee Rol "1" o-- "0..*" Permiso : agrupa Usuario *-- Email Usuario *-- EstadoCuenta PoliticaContrasenas ..> ContrasenaPlana : valida PoliticaContrasenas *-- RequisitoContrasena PoliticaBloqueoCuenta ..> Usuario : aplica sobre ``` **No existe una asociación entre Usuario y Permiso.** Es la decisión de diseño más importante de este bloque, y es estructural: para saber si un usuario puede hacer algo hay que atravesar sus roles, tanto en el código como en el modelo de datos. El requerimiento de seguridad que exige otorgar accesos únicamente por rol no queda librado a la disciplina de quien programa. ## Objetos de valor compartidos Tres conceptos aparecen en todo el sistema y merecen ser tipos propios en lugar de números y cadenas sueltas. ```mermaid classDiagram direction LR class Dinero { <> +int centavos +string moneda +desdeUnidades(u, moneda) Dinero$ +cero(moneda) Dinero$ +sumar(otro) Dinero +restar(otro) Dinero +multiplicarPor(factor) Dinero +porcentaje(p) Dinero +negado() Dinero +esMayorQue(otro) bool +esNegativo() bool +enUnidades() float } class Coordenada { <> +float latitud +float longitud +distanciaHasta(otra) float +equivaleA(otra) bool } class RangoFechas { <> +DateTime desde +DateTime hasta +dias() int +noches() int +contiene(fecha) bool +seSolapaCon(otro) bool +yaComenzo(ahora) bool } ``` `Dinero` guarda centavos enteros y se niega a operar entre monedas distintas: el precio de un paquete y la comisión de la plataforma no pueden sumarse mal por un error de coma flotante ni mezclarse con otra divisa. `Coordenada` valida su rango al construirse y calcula la distancia sobre la esfera, que es lo que hace posible la búsqueda por cercanía. `RangoFechas` cuenta días y noches como los cuenta una agencia de viajes, y se niega a existir si el regreso es anterior a la salida. ## Agencias Este bloque es el primer contexto de negocio, y lo interesante que tiene para contar son dos decisiones: **qué se valida y qué no**, y **qué no es una propiedad de la agencia**. ```mermaid classDiagram direction LR class Agencia { -int id -int usuarioId -string nombreComercial -string razonSocial -Cuit cuit -LegajoEvt legajo -string telefono -DateTime creadaEn +registrar(usuarioId, nombre, razon, cuit, legajo, tel, ahora) Agencia$ } class Cuit { <> +string valor +formateado() string +equivaleA(otro) bool } class LegajoEvt { <> +int LARGO_MAXIMO$ +string valor +equivaleA(otro) bool } class AgenciaYaRegistrada { <> +porCuit(Cuit) AgenciaYaRegistrada$ +porLegajo(LegajoEvt) AgenciaYaRegistrada$ } class AgenciaNoEncontrada { <> +paraLaCuenta() AgenciaNoEncontrada$ } Agencia *-- Cuit Agencia *-- LegajoEvt Agencia ..> AgenciaYaRegistrada : lanza Agencia ..> AgenciaNoEncontrada : lanza Usuario "1" ..> "0..1" Agencia : administra ``` **La clase es deliberadamente chica, y esa es la noticia.** Una entidad de dominio con siete atributos y un solo constructor no parece material de defensa hasta que se cuenta lo que no tiene y por qué. ### La agencia no tiene estado `Agencia` no tiene un estado —pendiente, aprobada, rechazada, suspendida— ni una máquina de transiciones que lo mueva, ni métodos para aprobarla, rechazarla o suspenderla, ni una auditoría de esas decisiones. El motivo es de modelo y no de código: **Travia es un servicio por suscripción.** Una agencia se registra, contrata un plan y empieza a usarlo. No hay nadie en el medio que la habilite, así que no hay un trámite cuyo estado registrar ni un historial de decisiones que auditar. Lo que va a decidir si puede publicar es **su suscripción vigente**, que no es una propiedad de la agencia sino una entidad aparte con su propia vigencia. Dos cosas conviene tener claras sobre esa decisión, porque son las que se preguntan: - **No se dejó a la agencia "aprobada por defecto".** Habría sido más barato y es exactamente lo que no había que hacer: un estado con cuatro valores de los cuales tres no ocurren nunca es una explicación pendiente disfrazada de dato. Cuando un atributo deja de distinguir algo, lo que corresponde es sacarlo. - **Una agencia existe o está dada de baja**, y eso lo dice el borrado lógico. No hace falta un enum para expresar dos situaciones que el modelo ya distingue. El criterio transferible: **una propiedad pertenece a la entidad solo si el negocio la decide sobre esa entidad**. La capacidad de publicar no la decide la agencia: la decide un contrato que se compra, que vence y que se renueva. Modelarla como columna de `agencias` habría atado dos ciclos de vida distintos al mismo objeto, y el día de la primera suscripción vencida habría hecho falta un mecanismo para mantenerlos sincronizados. ### Por qué el CUIT y el legajo son tipos y no cadenas Son los dos datos que distinguen a una agencia real de cualquiera que complete un formulario, y ninguno de los dos es "un texto". Pero **validan cosas muy distintas**, y el contraste entre los dos es la parte interesante: es el criterio con el que se decide, en cualquier campo del sistema, si vale la pena validar. **El CUIT no se valida contando once dígitos.** El último es un dígito verificador que se calcula por módulo 11 sobre los diez anteriores, con pesos `5 4 3 2 7 6 5 4 3 2`. Sin comprobarlo, cualquier número inventado de once cifras entra como válido y el error recién se descubre al facturar, cuando ya hay una venta hecha y un comprobante que emitir. Se validan además los prefijos posibles —20, 23, 24, 27 para personas físicas y 30, 33, 34 para jurídicas—, porque un CUIT que empieza con 99 no existe aunque su verificador cierre. **El legajo EVT no valida su formato, y eso es deliberado.** `LegajoEvt` solo exige que haya algo y que entre en la columna (`LARGO_MAXIMO`, 20 caracteres). Ni largo fijo, ni "solo dígitos", ni prefijo. Exigir exactamente cinco dígitos, que es lo que miden actualmente los legajos del registro, sería la regla obvia. No se exige, por dos motivos que se sostienen solos: - **El registro es secuencial y sigue creciendo.** Cinco dígitos es una observación del presente, no una regla del dominio. En cuanto el registro pase a seis, la validación rechaza agencias legítimas. - **No protegería de nada.** Un número inventado de cinco dígitos pasaría igual. Ninguna seguridad ganada, una falla futura garantizada. **El contraste es el argumento.** El CUIT se valida porque su verificador permite **decidir solo**: con el número alcanza para saber que está mal. El legajo no tiene ningún mecanismo equivalente; para saber si es auténtico hay que mirar el registro público, y no existe una API contra la cual hacerlo. El criterio general que queda escrito es este: **se valida lo que la validación puede resolver por sí misma.** Una comprobación sintáctica en el otro caso no agrega seguridad, solo agrega la sensación de que algo se comprobó —y rechaza datos válidos el día que la realidad cambia—. **La conclusión conviene decirla sin adornos: lo que no se puede validar tampoco se verifica.** No hay un administrador que contraste el legajo contra el registro público antes de habilitar a la agencia: el legajo **se pide, se exige único y se guarda, y nadie lo comprueba después**. Que esté presente y sea único no significa que sea auténtico. Es una limitación del sistema y se declara como tal, porque una limitación documentada es una decisión y una escondida es un hallazgo del jurado. Si más adelante el negocio decide que el legajo tiene que comprobarse, quedan dos caminos abiertos: un comprobante que la agencia adjunta al contratar su plan, o una revisión de administración. **Entonces, ¿por qué `LegajoEvt` sigue siendo un tipo y no un `string`?** Por tres razones que no dependen del formato: 1. **Normaliza.** Recorta los espacios y conserva los ceros a la izquierda, así que ` 00123 ` y `00123` son el mismo valor antes de tocar el índice único. Sin eso, la unicidad del legajo no significaría nada. 2. **Hace imposible el argumento cruzado.** Un método que recibe `LegajoEvt` no puede recibir por error el CUIT, la razón social ni el teléfono. Con tres cadenas seguidas en una firma, eso es cuestión de tiempo; el compilador no ayuda con `string`, sí con un tipo. 3. **Es el lugar donde vive la regla, sea cual sea.** Hoy la regla es "no vacío y entra en la columna". Si mañana el organismo publica un formato estable o aparece una API para contrastar, hay **un solo archivo** donde eso se escribe, y todo el sistema lo hereda. Si el legajo fuera un `string`, esa regla futura habría que ir a buscarla a cada validación del código. ### Lo que la entidad sí hace, y no es poco `registrar()` es el único constructor del alta y **normaliza lo que se escribe a mano**: recorta el nombre comercial, la razón social y el teléfono. Un espacio de más al final de "Sur Viajes " es un descuido de tipeo y no parte del nombre, y si entra a la base entra para siempre. La fecha de creación tampoco la inventa la entidad: llega desde el puerto `Reloj`, así que una prueba puede fijar el instante y verificarlo sin depender de "ahora". La entidad **tampoco se inventa su identificador**: `id` es nulo hasta que el repositorio la persiste y devuelve la entidad con el suyo. Es lo que permite que `Agencia` no sepa que existe una base de datos. ## Planes y suscripciones Este bloque es **el que reemplaza a una puerta administrativa**: la oferta comercial y su contratación. Tiene cuatro decisiones para contar: qué significa un límite, qué precio vale, por qué el estado de una suscripción no se guarda en ninguna parte y por qué el cobro entra por un puerto. ```mermaid classDiagram direction LR class Plan { -int id -string nombre -Dinero precioMensual -LimitesDelPlan limites -string[] beneficios -bool activo -bool esRecomendado +nuevo(nombre, precio, limites, ...) Plan$ +conDatos(...) Plan +seSigueOfreciendo() bool } class LimitesDelPlan { <> +int maxPaquetesActivos +int maxDestacadosMes +sinLimites() LimitesDelPlan$ +permiteOtroPaqueteActivo(activosHoy) bool +permiteOtroDestacadoEsteMes(delMes) bool +paquetesActivosSonIlimitados() bool +destacadosSonIlimitados() bool +equivaleA(otro) bool } class Suscripcion { -int id -int agenciaId -int planId -Dinero precioContratado -RangoFechas periodo -EstadoSuscripcion estado -string claveIdempotencia -string referenciaDeCobro -DateTime contratadaEn +contratar(agenciaId, plan, ahora, clave, ref) Suscripcion$ +estaVigenteAl(momento) bool +diasParaVencerAl(momento) int +situacionAl(momento, diasDeAviso) SituacionDeSuscripcion +cancelada() Suscripcion } class EstadoSuscripcion { <> Activa Cancelada +siguePagada() bool } class SituacionDeSuscripcion { <> Vigente PorVencer SuspendidaPorImpago Cancelada +puedePublicar() bool +requiereAvisoDeRenovacion() bool } class PasarelaDeCobro { <> +cobrar(solicitud) ResultadoDeCobro } class SolicitudDeCobro { <> +Dinero importe +string concepto +string claveIdempotencia +int agenciaId } class ResultadoDeCobro { <> +bool fueAprobado +string referencia +string motivo +aprobado(referencia) ResultadoDeCobro$ +rechazado(motivo) ResultadoDeCobro$ } class CobroRechazado { <> } Plan *-- LimitesDelPlan Plan *-- Dinero : precio mensual Suscripcion *-- Dinero : precio congelado Suscripcion *-- RangoFechas Suscripcion *-- EstadoSuscripcion Suscripcion ..> SituacionDeSuscripcion : deriva Suscripcion ..> Plan : congela el precio de Agencia "1" --> "0..*" Suscripcion : contrata PasarelaDeCobro ..> SolicitudDeCobro : recibe PasarelaDeCobro ..> ResultadoDeCobro : devuelve PasarelaDeCobro ..> CobroRechazado : provoca ``` **`NULL` es "ilimitado" y `0` es "ninguno", y son cosas distintas.** Es la convención que `LimitesDelPlan` existe para encapsular: un plan con `maxDestacadosMes = 0` no permite destacar nada, uno con `null` permite destacar siempre. La alternativa habitual —un entero con un valor mágico, `-1` o `9999`— funciona hasta que alguien le suma uno y la cuenta deja de tener sentido. Que la comparación viva en un objeto de valor y no en un `if` de cada caso de uso es lo que evita que el tratamiento del nulo se disperse: el alta de paquetes, el panel que avisa "te quedan 2 de 15" y cualquier informe de consumo **preguntan, no recalculan**. **El precio se congela al contratar y no se consulta después.** `Suscripcion.precioContratado` es una copia del precio que tenía el plan ese día, no una referencia a él. Si mañana la administración sube el plan, quien ya pagó sigue debiendo lo que pagó hasta que termine su mes: un aumento rige para la próxima renovación, nunca para el período en curso. Si el importe se leyera del plan al mostrar la factura, el comprobante de agosto diría en septiembre otra cosa de la que se cobró. **La situación de una suscripción no se persiste: se deriva.** `EstadoSuscripcion` —lo único que se guarda— tiene dos valores, `Activa` y `Cancelada`. Los cuatro que alguien necesita ver viven en `SituacionDeSuscripcion` —`Vigente`, `PorVencer`, `SuspendidaPorImpago`, `Cancelada`— y los calcula `situacionAl($ahora)` comparando el período contra el reloj. **«Vencida» no es un valor persistido**, y esa ausencia es el diseño: ningún proceso nocturno tiene que salir a marcar filas y nadie depende de que ese proceso haya corrido. El **orden de las preguntas** forma parte de la regla y es lo que conviene tener listo para la defensa: 1. **La cancelación le gana al calendario.** Se pregunta primero por el estado: quien se dio de baja se informa como cancelado aunque le queden días pagos, porque decir "suspendida por impago" de quien decidió irse sería acusarlo de algo que no hizo. 2. **Después el calendario.** Fuera del período no hay servicio, y el motivo práctico para la agencia es siempre el mismo: falta renovar. 3. **`PorVencer` habilita a publicar.** El mes está pagado, así que el aviso es información y no una restricción. Recortar el servicio antes de que termine el período cobrado sería cobrar un mes y entregar tres semanas. Los días de aviso **llegan por parámetro y no como constante**: cuántos días antes se avisa es una decisión comercial, del mismo tipo que un precio, y no una propiedad del dominio. **El cobro entra por un puerto, y es la mejor demostración de la arquitectura que tiene el proyecto.** `PasarelaDeCobro` recibe una `SolicitudDeCobro` —importe, concepto, clave de idempotencia y agencia— y devuelve un `ResultadoDeCobro` —si fue aprobado, la referencia del pago y el motivo del rechazo—. El dominio no sabe que Mercado Pago existe: cambiar de proveedor es cambiar de adaptador, sin tocar el caso de uso. El rechazo es parte del contrato del puerto: `CobroRechazado` se traduce a 402, sea cual sea la pasarela que rechace. **La clave de idempotencia forma parte de la identidad del contrato.** Dos envíos del mismo formulario —el doble clic, o el reintento del navegador ante una respuesta lenta— traen la misma clave, y una clave admite una sola suscripción. Sin eso la agencia terminaría con dos suscripciones superpuestas y, lo que importa más, con dos cobros. ## Paquetes y países Este bloque **consulta** al de arriba: antes de existir una fila, `PoliticaDePublicacion` le pregunta a la suscripción y al plan si hay lugar. ```mermaid classDiagram direction LR class Paquete { -int id -int agenciaId -string nombre -Trayecto trayecto -RangoFechas viaje -Cupo cupo -Dinero precio -EstadoPaquete estado +publicar(agenciaId, nombre, trayecto, viaje, cupo, precio, ahora, ...) Paquete$ +situacionAl(ahora) SituacionDePaquete +empiezaAOcuparLugarAl(ahora, cambios) bool +conNuevosDatos(...) Paquete +despublicado() Paquete +reactivado() Paquete +duracionEnDias() int } class Trayecto { <> -CodigoPais paisOrigen -CodigoPais paisDestino -string ciudadDestino +paises() CodigoPais[] +exigirPaisesElegibles(vigentes) } class Cupo { <> +int totales +int disponibles +conNuevosTotales(totales) Cupo +vendidos() int +agotado() bool } class EstadoPaquete { <> Activo Despublicado } class SituacionDePaquete { <> +ocupaCupoDelPlan() bool +estaCerrado() bool +estaAgotado() bool +estaDisponible() bool } class PoliticaDePublicacion { <> +evaluar(situacionSuscripcion, plan, activosHoy, ofertaVigente) PermisoDePublicacion } class PermisoDePublicacion { <> +bool concedido +MotivoDeRechazo motivo +consumoAlOcuparOtroLugar() ConsumoDelPlan } class MotivoDeRechazo { <> SinSuscripcionVigente LimiteDePaquetesAlcanzado } class Pais { -CodigoPais codigo -string nombre +vigente() bool } class CodigoPais { <> +string valor +iguala(otro) bool } Paquete "1" *-- "1" Trayecto : tiene Paquete "1" *-- "1" Cupo : tiene Trayecto "0..*" ..> CodigoPais : referencia sin FK PoliticaDePublicacion ..> PermisoDePublicacion : produce PermisoDePublicacion "1" -- "0..1" MotivoDeRechazo : explica ``` **`Paquete::empiezaAOcuparLugarAl()` es el único método que decide si hay que preguntarle al plan, y responde distinto según qué se está haciendo.** Publicar siempre pregunta. Reactivar siempre pregunta —un despublicado no ocupaba ningún lugar y va a volver a ocupar uno—. Editar sólo pregunta si el cambio mueve un paquete **cerrado** —fecha de salida vencida— de vuelta al futuro: corregir el precio o la descripción de un paquete que ya estaba activo no pregunta nada, porque no suma ningún lugar nuevo. Es la regla que sostiene por qué una agencia con la suscripción vencida puede seguir editando lo que ya tiene, sin poder sumar nada. **`CodigoPais` no valida formato más allá de ser dos letras, y no le hace falta.** A diferencia del `LegajoEvt`, acá sí existe un universo cerrado contra el cual comparar —el catálogo `paises`—, así que la validación real no la hace el objeto de valor sino `Trayecto::exigirPaisesElegibles()` contra los códigos vigentes que le llegan resueltos. Es el mismo criterio que ya separa a `Cuit` de `LegajoEvt`: se valida cuando hay contra qué decidir. **Ni `cantidad_dias`, ni "agotado", ni "cerrado" son propiedades guardadas.** `SituacionDePaquete` las deriva de `Cupo` y de `RangoFechas` contra el reloj, cada vez que se pregunta. Es el mismo criterio que `Suscripcion::situacionAl()` aplica para no guardar "vencida", y con esta entidad ya son dos tablas seguidas que lo repiten: empieza a ser un patrón del proyecto y no una decisión suelta. ## Núcleo de negocio Este bloque es el modelo conceptual de la oferta, la venta y el dinero, y es donde se ve cómo encajan entre sí las piezas de los bloques anteriores: órdenes, pagos, asientos y reseñas alrededor de la agencia y el paquete. Las clases que se repiten se dibujan acá por sus relaciones y con los métodos que suman en este bloque. `Paquete` aparece en su forma conceptual, con sus operaciones de reserva; su estructura detallada —`Trayecto`, `Cupo` y `SituacionDePaquete`— es la del bloque «Paquetes y países». **`puedePublicar()` no consulta ninguna propiedad de la agencia: le pregunta a su suscripción.** Es la contracara de la decisión de arriba —la agencia no tiene estado— y el motivo por el que la capacidad de publicar aparece en este bloque y no en el anterior. `Suscripcion` sabe decir su situación y `LimitesDelPlan` sabe decir si entra un paquete más, y el alta de un paquete le entrega las dos respuestas al servicio de dominio `PoliticaDePublicacion` justo antes de escribir la fila, que es el único momento en el que la pregunta cambia algo. ```mermaid classDiagram direction TB class Agencia { -int id -Cuit cuit -LegajoEvt legajo -Coordenada ubicacion +puedePublicar(ahora) bool +saldo() Dinero +reputacion() float } class Plan { -int id -string nombre -Dinero precioMensual -LimitesDelPlan limites +seSigueOfreciendo() bool } class Suscripcion { -int id -Dinero precioContratado -RangoFechas periodo -EstadoSuscripcion estado +estaVigenteAl(momento) bool +situacionAl(momento) SituacionDeSuscripcion } class Paquete { -int id -string nombre -string ciudadDestino -Coordenada ubicacionDestino -RangoFechas salida -int cuposTotales -int cuposDisponibles -Dinero precio -EstadoPaquete estado +hayCupoPara(pasajeros) bool +reservar(pasajeros) +liberar(pasajeros) +duracionEnDias() int +despublicar() +restaurar() } class Itinerario { -int dia -string titulo -string descripcion -Coordenada punto } class Orden { -int id -EstadoOrden estado -int cantidadPasajeros -Dinero importeTotal -DateTime reservaVenceEn +confirmar(ahora) +cancelar(motivo) +estaVencida(ahora) bool +admiteResenia(ahora) bool } class Pasajero { -string nombre -string apellido -string documento } class Pago { -string referenciaExterna -EstadoPago estado -Dinero importe +estaAprobado() bool } class Asiento { -int id -TipoAsiento tipo -Dinero importe -string concepto -DateTime registradoEn +esReversoDe(otro) bool } class Resenia { -int id -int calificacion -string comentario } class BandaDePrecios { <> +calcular(destino, duracion, temporada) BandaDePrecios +percentil25() Dinero +percentil50() Dinero +percentil75() Dinero +ubicar(precio) string } class ScoreReputacion { <> +calcular(agencia) float } Usuario "1" -- "0..1" Agencia : administra Agencia "1" --> "0..*" Paquete : publica Agencia "1" --> "0..*" Suscripcion : contrata Plan "1" --> "0..*" Suscripcion : define Agencia "1" --> "0..*" Asiento : acumula Paquete "1" *-- "0..*" Itinerario : detalla Paquete "1" --> "0..*" Orden : origina Usuario "1" --> "0..*" Orden : genera Orden "1" *-- "1..*" Pasajero : incluye Orden "1" --> "0..1" Pago : liquida Orden "1" --> "0..1" Resenia : habilita Orden "1" --> "0..*" Asiento : genera BandaDePrecios ..> Paquete : analiza ScoreReputacion ..> Agencia : evalúa ``` ## Decisiones del modelo **La agencia guarda el identificador de su cuenta, no la cuenta.** `Agencia` tiene un `usuarioId` y no una referencia a `Usuario`. Son dos contextos distintos, persistidos en dos esquemas distintos, y si la agencia tuviera la entidad entera adentro cualquier operación sobre una agencia arrastraría una lectura del esquema de identidad. La asociación del diagrama aparece punteada justamente por eso: existe en el negocio, pero ninguna de las dos clases navega hacia la otra. **El derecho a publicar no es de la agencia, es de un contrato.** Por eso `Suscripcion` es una entidad aparte y no un par de columnas de `agencias`, y por eso la relación es de cero a muchas: una agencia acumula suscripciones a lo largo del tiempo, cada una con su precio, su período y su referencia de cobro, y el historial es lo que permite responder qué se le cobró y cuándo. Guardar solo la última habría ahorrado una tabla y perdido la respuesta. **El saldo de la agencia no es un atributo, es un cálculo.** `Agencia.saldo()` recorre sus asientos y los suma. No hay ninguna columna de saldo que pueda quedar desincronizada con los movimientos que la produjeron, y no hay ningún camino por el que el saldo cambie sin dejar un asiento que lo explique. Una corrección se hace con un asiento de reverso, no editando un número. **El cupo vive en el paquete, no en la orden.** `Paquete.reservar()` y `Paquete.liberar()` son las dos únicas operaciones que mueven la disponibilidad, y ambas son responsabilidad de la entidad que la posee. La orden no toca el cupo por su cuenta: se lo pide al paquete. **La reserva tiene vencimiento explícito.** `Orden.reservaVenceEn` convierte una regla de negocio en un dato del modelo. Sin ese atributo, la liberación de cupos tendría que inferirse de la fecha de creación y una constante escondida en el código. **El itinerario es composición y los pasajeros también.** Un itinerario no existe fuera de su paquete, ni un pasajero fuera de su orden. Por eso son rombo lleno: se crean y se destruyen con su contenedor. Un paquete, en cambio, existe antes de la primera orden y sigue existiendo después. **Las reglas que no pertenecen a una sola entidad son servicios de dominio.** La banda de precios necesita ver todos los paquetes comparables del mercado y el score de reputación necesita ver todas las reseñas de la agencia: ninguna de las dos cosas es responsabilidad de una entidad individual, y forzarlas dentro de una haría que esa entidad tuviera que conocer el catálogo entero.