CAPÍTULO 5 · Ver un botón no concede permiso
Una acción necesita dejar una explicación después de ocurrir
Mientras desarrollamos, sabemos qué botón acabamos de pulsar. En una plataforma compartida esa certeza desaparece: varias personas pueden actuar en momentos distintos y una pregunta sobre un cambio puede llegar mucho después. Tener el estado actual de una tabla no explica por sí solo cómo se llegó a él.
Incorporamos trazabilidad para las acciones relevantes. El registro debe permitir relacionar actor, operación, momento y resultado, con información suficiente para investigar y sin convertir los logs en otro depósito de secretos. También distinguimos un intento rechazado de un cambio confirmado; ambos pueden importar, pero cuentan historias diferentes.
La auditoría nos ayuda a mirar hacia atrás. Sin embargo, antes de dar por terminada una acción debemos asegurar que realmente ocurrió como una unidad. Si una operación guarda varias cosas y falla a mitad de camino, o si el cliente la repite por falta de respuesta, un buen registro no basta para corregir su inconsistencia.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Un registro de cambios con contexto
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Actor. Ejecuta una acción
- Servicio. Aplica el cambio autorizado
- Estado. Guarda el resultado
- Auditoría. Conserva quién, qué y cuándo
01 / EL PROBLEMA
¿Para qué sirve?
Un log técnico dice que una función falló. Una auditoría explica quién cambió qué, cuándo y cuál fue la operación. No son intercambiables.
02 / COMPRENDER
El concepto, explicado
Un mixin puede envolver Commands, pero su contrato debe distinguir éxito y fallo. Captura el valor de un objeto antes de borrarlo.
Decide si el registro es obligatorio y transaccional o de mejor esfuerzo. Si la operación debe ser indivisible de su auditoría, guarda ambos dentro de la misma transacción.
03 / CONSTRUIR
Implementación paso a paso
- Define actor, acción y entidad.
- Versiona el modelo de auditoría.
- Registra solo eventos de negocio confirmados.
- Prueba qué ocurre si el log falla.
04 / APLICAR
Ejemplo en SensorHub
# Esquema de servicio con auditoría obligatoria.
from django.db import transaction
@transaction.atomic
def rename_sensor(*, user, sensor, new_code):
previous = sensor.code
sensor.code = new_code
sensor.save(update_fields=["code"])
AuditEvent.objects.create(
actor=user, action="rename_sensor", entity_id=str(sensor.pk),
before={"code": previous}, after={"code": new_code},
)
return sensorCómo leer el ejemplo
- AuditEvent es un modelo del ejemplo que debe definirse con campos actor, action, entity_id, before y after.
- Si guardar el log falla, atomic revierte el cambio de código.
- El servicio no debe registrar tokens, contraseñas o payloads completos innecesarios.
Error habitual
Un print de errores de auditoría no ofrece trazabilidad durable. Define retención, acceso y correlación con peticiones.
05 / PRACTICAR
Tu turno
Fuerza una excepción al crear AuditEvent y revisa sensor.code.
Ver solución orientativa
El cambio debe revertirse cuando la auditoría es obligatoria. Si eliges mejor esfuerzo, documenta y prueba ese comportamiento distinto.
06 / VERIFICAR
Cómo sabes que funciona
- Una operación fallida no aparece como exitosa.
- Cada evento contiene identidad de la entidad afectada.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Transacciones e idempotencia →Continuar en modo relato