14. Reglas de negocio: condiciones, restricciones, cálculos y decisiones

14.1 Introducción

Las reglas de negocio indican qué debe cumplirse dentro del dominio. Pueden expresar condiciones, restricciones, cálculos, decisiones, autorizaciones, límites o políticas. Son una parte esencial del modelo de dominio porque explican cómo deben comportarse los conceptos importantes.

Un modelo que solo muestra entidades, atributos y relaciones puede parecer ordenado, pero será incompleto si no incluye reglas. En la práctica, muchas fallas de software aparecen porque una regla fue omitida, interpretada de forma ambigua o implementada en un lugar incorrecto.

14.2 Imagen conceptual de reglas de negocio

14.3 Qué es una regla de negocio

Una regla de negocio es una declaración que limita, guía o determina el comportamiento del dominio. No describe una preferencia técnica, sino una condición que proviene del negocio, de una política interna, de una norma externa o de una necesidad operativa.

Por ejemplo: "Un paciente no puede reservar dos turnos pendientes para la misma especialidad", "Una cancelación debe realizarse con al menos 24 horas de anticipación" o "El importe final se calcula aplicando descuento antes de impuestos".

14.4 Reglas de condición

Las reglas de condición indican cuándo algo puede ocurrir. Suelen expresarse con frases como "si", "solo si", "cuando", "mientras" o "siempre que".

Ejemplos:

• Un turno puede cancelarse solo si todavía no fue atendido.
• Una agenda puede publicarse cuando tiene al menos una franja horaria válida.
• Un paciente puede reservar si no tiene restricciones activas.

Estas reglas ayudan a definir condiciones previas para acciones del dominio.

14.5 Reglas de restricción

Las reglas de restricción indican límites que no deben violarse. Pueden referirse a cantidades, estados, combinaciones, fechas, rangos o relaciones entre conceptos.

Por ejemplo, una franja horaria no debe superponerse con otra dentro de la misma agenda. Un pedido no puede confirmarse sin ítems. Un descuento no puede superar cierto porcentaje. Un paciente no puede tener más de una reserva pendiente con el mismo profesional para el mismo día.

Las restricciones suelen ser candidatas a invariantes, tema que veremos en el próximo capítulo.

14.6 Reglas de cálculo

Las reglas de cálculo determinan cómo obtener un valor a partir de otros datos. Pueden incluir fórmulas, prioridades, redondeos, impuestos, descuentos, recargos o criterios de duración.

En un dominio de turnos, la duración de un turno puede depender de la especialidad, del profesional o del tipo de atención. En un dominio de ventas, el total de un pedido puede depender de ítems, impuestos, descuentos y gastos de envío.

14.7 Reglas de decisión

Las reglas de decisión determinan qué camino tomar ante determinadas condiciones. Pueden responder preguntas como: ¿se aprueba o se rechaza?, ¿qué prioridad corresponde?, ¿qué estado debe asignarse?, ¿qué política se aplica?

Por ejemplo, si un paciente cancela fuera de término, el sistema puede registrar una inasistencia. Si una agenda no tiene disponibilidad, el sistema puede ofrecer lista de espera. Si un pedido supera cierto monto, puede requerir autorización adicional.

Estas reglas suelen representarse bien con tablas de decisión, árboles de decisión o casos concretos.

14.8 Reglas de autorización

Algunas reglas indican quién puede realizar una acción. Aunque la seguridad técnica se implemente luego, el dominio puede tener reglas propias sobre permisos y responsabilidades.

Por ejemplo, un paciente puede cancelar sus propios turnos, pero no los de otro paciente. Un administrativo puede reprogramar turnos dentro de una sede. Un profesional puede bloquear franjas de su agenda, pero quizás no pueda modificar agendas de otros profesionales.

Estas reglas conectan roles, acciones y límites del negocio.

14.9 Reglas temporales

Muchas reglas dependen del tiempo. Una cancelación puede permitirse hasta 24 horas antes. Una promoción puede estar vigente durante un período. Una cobertura médica puede estar activa hasta una fecha. Un turno puede pasar a vencido si no se confirma a tiempo.

Las reglas temporales requieren especial cuidado porque involucran fechas, horarios, zonas horarias, días hábiles, feriados o períodos de vigencia. El modelo debe expresar claramente qué momento se toma como referencia.

14.10 Reglas explícitas e implícitas

Algunas reglas están escritas en documentos formales. Otras aparecen en conversaciones o en la práctica diaria. Estas últimas son reglas implícitas y pueden ser peligrosas si no se descubren, porque los expertos del negocio las dan por obvias pero el equipo técnico no las conoce.

Por ejemplo, un administrativo puede decir: "Nunca damos sobreturnos los viernes a la tarde". Si esa política afecta el sistema, debe registrarse como regla. No alcanza con dejarla como comentario informal de una reunión.

14.11 Reglas estables y reglas cambiantes

No todas las reglas cambian con la misma frecuencia. Algunas son estables porque pertenecen a la esencia del dominio. Otras cambian por decisiones comerciales, políticas internas, regulación, temporada o estrategia.

Por ejemplo, "un turno reservado ocupa una franja horaria" puede ser una regla bastante estable. En cambio, "la cancelación requiere 24 horas de anticipación" podría cambiar a 48 horas. Distinguir reglas estables y cambiantes ayuda a tomar mejores decisiones de diseño más adelante.

14.12 Reglas y lenguaje ubicuo

Las reglas deben escribirse usando el lenguaje ubicuo del dominio. Si el negocio habla de Turno, Paciente, Agenda, Franja horaria y Cancelación fuera de término, las reglas deberían usar esos términos.

Una regla expresada con vocabulario técnico puede perder claridad. Por ejemplo, "validar campo estado antes de insertar registro" no comunica lo mismo que "un turno atendido no puede cancelarse". La segunda frase pertenece al dominio y puede ser validada por expertos.

14.13 Ubicación de las reglas en el modelo

Durante el análisis, debemos identificar a qué concepto se relaciona cada regla. Algunas reglas pertenecen naturalmente a una entidad. Otras involucran varios conceptos y pueden requerir un servicio de dominio, una política o una regla explícita documentada.

Por ejemplo, "un turno no puede reservarse si la franja ya está ocupada" involucra Turno, Franja horaria y Agenda. "Un correo electrónico debe tener formato válido" puede pertenecer al objeto de valor Correo electrónico. "El total del pedido se calcula sumando ítems y descuentos" puede pertenecer a Pedido o a una política de precios, según el dominio.

14.14 Tabla de ejemplos

La siguiente tabla muestra distintos tipos de reglas:

14.15 Cómo descubrir reglas

Para descubrir reglas de negocio, conviene buscar expresiones y situaciones como:

• Frases con "si", "solo si", "excepto", "siempre", "nunca", "al menos" o "como máximo".
• Casos alternativos y excepciones en casos de uso.
• Campos obligatorios, rangos permitidos y límites de cantidad.
• Estados que impiden o habilitan acciones.
• Cálculos que el negocio realiza manualmente.
• Decisiones tomadas por personas expertas.
• Políticas internas, normas legales y procedimientos escritos.

14.16 Validar reglas con ejemplos

Una regla debe probarse con ejemplos y contraejemplos. Si la regla dice que un paciente no puede tener dos turnos pendientes para la misma especialidad, debemos preguntar qué ocurre si los turnos son con profesionales distintos, en sedes distintas, en fechas distintas o si uno de ellos ya está confirmado.

Los ejemplos revelan límites, excepciones y condiciones ocultas. También ayudan a convertir reglas ambiguas en reglas verificables.

14.17 Errores frecuentes

Al trabajar con reglas de negocio, suelen aparecer estos errores:

• Dejar reglas importantes solo en conversaciones informales.
• Escribir reglas con vocabulario técnico en lugar de lenguaje del dominio.
• Confundir reglas de negocio con validaciones de interfaz.
• No distinguir reglas estables de políticas cambiantes.
• No indicar qué conceptos participan en una regla.
• Implementar una regla antes de validarla con ejemplos.
• No revisar qué ocurre en casos excepcionales.

14.18 Qué debes recordar de este tema

• Las reglas de negocio indican qué debe cumplirse dentro del dominio.
• Pueden expresar condiciones, restricciones, cálculos, decisiones, autorizaciones o políticas.
• Deben escribirse con el lenguaje ubicuo del negocio.
• Una regla puede pertenecer a una entidad, a un objeto de valor, a una política o involucrar varios conceptos.
• Las reglas implícitas deben hacerse visibles para evitar errores.
• Las reglas deben validarse con ejemplos, contraejemplos y expertos del dominio.
• No conviene confundir reglas de negocio con detalles de interfaz o implementación.

14.19 Conclusión

Las reglas de negocio son una parte central del modelado de dominio. Explican qué acciones están permitidas, qué restricciones se deben respetar, cómo se calculan valores y qué decisiones debe tomar el sistema. Sin reglas claras, el modelo queda incompleto y el software puede comportarse de manera incorrecta aunque técnicamente funcione.

En el próximo tema estudiaremos los invariantes del dominio, es decir, aquellas propiedades que siempre deben cumplirse para que el modelo se mantenga válido.