System Design
Reglas de negocio
Explica cómo descubrir, documentar y validar reglas de negocio, distinguirlas de validaciones técnicas y relacionarlas con estados, decisiones y excepciones.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo descubrir, documentar y validar reglas de negocio, distinguirlas de validaciones técnicas y relacionarlas con estados, decisiones y excepciones.
Las reglas de negocio definen qué estados, cálculos, decisiones y transiciones son válidos para la organización. No son detalles de interfaz ni simples validaciones técnicas: protegen el significado del sistema.
Una regla de negocio expresa una política estable o versionada del dominio.
capacidad
→ confirmar pedido
regla
→ solo puede confirmarse si existe stock vendible suficienteEl requisito indica qué operación debe ofrecerse. La regla determina las condiciones bajo las cuales esa operación es válida.
Cuando las reglas quedan dispersas en pantallas, endpoints, jobs y hojas de cálculo aparecen contradicciones:
Centralizar el conocimiento no significa necesariamente una sola función o motor de reglas. Significa contar con una definición autoritativa, trazable y verificable.
hechos + contexto + regla vigente
→ decisión / cálculo / transiciónEjemplo:
Hechos: pedido por $120 000, cliente nuevo, pago contraentrega.
Contexto: sucursal Bogotá, política vigente desde julio.
Regla: clientes nuevos solo pueden usar contraentrega hasta $80 000.
Resultado: operación no elegible.Impiden estados imposibles: cantidad positiva, fechas coherentes o una asignación dentro de la misma sucursal.
Determinan quién puede acceder a una capacidad: descuento, crédito, devolución o rol operativo.
Definen impuestos, comisiones, disponibilidad, saldos y totales. Deben precisar orden, redondeo y moneda.
Controlan cambios de estado: un pedido entregado no vuelve a preparación; una devolución requiere venta previa.
Obtienen una categoría o resultado a partir de hechos: cliente moroso, pedido prioritario o stock bajo.
Responden quién puede tomar una decisión en el dominio, diferente de permisos técnicos generales.
Cambian por fecha, región, plan, canal o regulación.
Permiten apartarse de la regla bajo autoridad, evidencia y auditoría.
Validación técnica
→ el email tiene formato válido
Regla de negocio
→ el email debe ser único dentro del negocio
Requisito funcional
→ registrar una cuenta
Restricción
→ usar identidad corporativa existenteLa diferencia importa porque cada elemento cambia por razones distintas y tiene diferentes owners.
ID:
Enunciado preciso:
Motivación:
Fuente / owner:
Datos requeridos:
Ámbito:
Vigencia:
Prioridad:
Excepciones:
Resultado si se incumple:
Ejemplos y contraejemplos:
Artefactos relacionados:Evita palabras vagas como “normalmente”, “adecuado” o “según corresponda” sin indicar quién decide.
RB-INV-03
Un producto no puede tener stock vendible negativo en una sucursal.
Stock vendible = stock físico − reservado − bloqueado.La regla no especifica si se implementa con una transacción, constraint o cola. Sí define una invariante que debe mantenerse bajo concurrencia.
Reglas posibles:
pending puede cancelarse por cliente u operador.confirmed solo puede cancelarse antes de preparing o mediante autorización especial.delivered no se cancela; se inicia devolución.Estas reglas afectan estado, permisos, inventario, auditoría y experiencia del usuario. No deben vivir únicamente en el botón de una pantalla.
Útiles cuando varias condiciones producen resultados combinatorios.
| Estado | Pago | Actor | Resultado |
|---|---|---|---|
| pending | no cobrado | cliente | cancelar |
| confirmed | cobrado | cliente | solicitar revisión |
| confirmed | cobrado | manager | cancelar y reembolsar |
| delivered | cobrado | cualquiera | iniciar devolución |
La tabla hace visibles huecos y conflictos mejor que una cadena de if narrada.
Dos reglas pueden competir. Ejemplo:
Regla general: no aceptar pedidos fuera del horario.
Excepción prioritaria: pedidos programados pueden registrarse para el día siguiente.Define precedencia explícita. El orden accidental de evaluación en código no debe decidir política.
Una regla puede cambiar sin que el pasado deba reinterpretarse.
comisión 5 % hasta 2026-07-31
comisión 6 % desde 2026-08-01Decide si los registros históricos conservan:
Recalcular siempre con la regla actual puede alterar reportes históricos.
Una regla puede ser correcta en una solicitud aislada y fallar con dos simultáneas.
“solo un repartidor activo por pedido”Debe sostenerse aunque dos operadores asignen al mismo tiempo. La especificación debe incluir la invariante; el diseño elegirá constraint, lock, control optimista u otra coordinación.
Cuando varios sistemas participan, evita duplicar decisiones autoritativas sin protocolo.
Opciones:
Copiar lógica manualmente crea divergencia silenciosa.
Una excepción legítima necesita:
“Admin puede saltarse todo” destruye el modelo y dificulta investigar incidentes.
La regla puede devolver indeterminado, solicitar información o rechazar. No inventes defaults silenciosos.
Escala al owner y registra precedencia. No resuelvas por orden de implementación.
Define si afecta operaciones existentes o solo nuevas.
Reglas de vigencia deben indicar zona y límites inclusivos.
Los cálculos monetarios deben definir precisión, momento y método.
Si una regla consulta scoring o regulación externa, modela timeout y decisión temporal.
Los datos históricos pueden violar reglas actuales; decide migración, grandfathering o bloqueo.
Produce resultados distintos. Mantén una fuente y referencias.
Otros canales pueden omitirla. Protégela en el dominio y persistencia cuando sea posible.
Se convierte en bypass permanente.
Un estado debe tener significado y transiciones, no solo color visual.
Altera evidencia y conciliación.
Una librería compleja no soluciona definiciones pobres. Empieza por claridad y volumen real de cambio.
Según la regla, puede existir defensa en varias capas:
UI
→ feedback temprano
aplicación / dominio
→ decisión y mensaje de negocio
base de datos
→ invariante concurrente
integración
→ contrato y reconciliaciónNo toda regla cabe en una constraint, pero las invariantes críticas no deben depender solo de una pantalla.
Puede aportar cuando hay gran volumen de políticas configurables, cambios frecuentes por negocio, múltiples dimensiones y necesidad de explicación. Puede ser mala decisión cuando las reglas son pocas, fuertemente acopladas al dominio o el equipo no puede operar otra plataforma.
Priorización y alcance de entrega decide qué capacidades y riesgos deben abordarse primero bajo recursos limitados.