18. Comandos, consultas y eventos: distinguir intención, lectura y resultado
18.1 Introducción
En un modelo de dominio dinámico conviene distinguir tres ideas: comandos, consultas y eventos. Un comando expresa una intención de cambiar algo. Una consulta pide información sin modificar el dominio. Un evento indica que algo importante ya ocurrió.
Separar estas ideas mejora la claridad del análisis. Evita confundir lo que alguien quiere hacer, lo que alguien necesita saber y lo que efectivamente sucedió en el negocio. También ayuda a descubrir reglas, permisos, resultados esperados y consecuencias.
18.2 Imagen conceptual
18.3 Qué es un comando
Un comando representa una intención de realizar una acción que puede modificar el estado del dominio. Se formula normalmente en infinitivo o imperativo: Reservar turno, Cancelar turno, Confirmar pago, Publicar agenda, Aprobar solicitud.
Un comando puede ser aceptado o rechazado. Si un paciente intenta reservar un turno, el dominio debe verificar reglas: disponibilidad, restricciones, estado del turno, permisos y límites. Solo si las reglas se cumplen, el comando produce un cambio.
18.4 Qué es una consulta
Una consulta solicita información sin cambiar el estado del dominio. Por ejemplo: Consultar turnos disponibles, Ver agenda del profesional, Buscar paciente, Obtener historial de cancelaciones o Listar pedidos pendientes.
Las consultas pueden ser complejas y tener filtros, ordenamientos o cálculos de presentación, pero conceptualmente no deberían modificar el dominio. Su objetivo es responder una pregunta.
18.5 Qué es un evento
Un evento representa un hecho importante que ya ocurrió. Se nombra en pasado: Turno reservado, Turno cancelado, Agenda publicada, Pago registrado, Pedido confirmado. A diferencia del comando, el evento indica resultado ocurrido.
Un evento puede ser consecuencia de un comando aceptado, de una regla automática, de una integración externa o del paso del tiempo.
18.6 Comparación básica
La siguiente tabla resume la diferencia:
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Comando | ¿Qué se quiere hacer? | Reservar turno. |
| Consulta | ¿Qué se quiere saber? | Consultar turnos disponibles. |
| Evento | ¿Qué ocurrió? | Turno reservado. |
18.7 Ejemplo completo: reservar turno
Supongamos que un paciente desea reservar un turno. Antes de ejecutar la acción, puede realizar una consulta:
Luego, si elige una franja, envía un comando:
Si el dominio acepta el comando, se produce un evento:
Este evento puede cambiar el estado del turno y disparar consecuencias, como bloquear la franja o enviar una notificación.
18.8 Comandos y reglas previas
Los comandos deben validarse contra reglas del dominio. Por ejemplo, Cancelar turno puede requerir que el turno no esté atendido, que el usuario tenga permiso y que la cancelación cumpla una política de anticipación.
Si alguna regla falla, el comando no debería producir el evento esperado. Intentar cancelar no significa que el turno haya sido cancelado. Esta diferencia evita registrar hechos que no ocurrieron.
18.9 Consultas y decisiones
Las consultas no modifican el dominio, pero pueden ayudar a tomar decisiones. Consultar disponibilidad permite elegir una franja. Consultar historial de inasistencias puede ayudar a decidir si se permite una nueva reserva. Consultar saldo puede ayudar a decidir si se aprueba una compra.
Aun así, la decisión que modifica el dominio debe expresarse como comando o regla, no como consulta. Una consulta responde; no ordena cambiar.
18.10 Eventos y consecuencias posteriores
Cuando ocurre un evento, pueden dispararse consecuencias. Turno reservado puede enviar una confirmación. Turno cancelado puede liberar una franja. Pago registrado puede cambiar el estado de un pedido. Paciente ausente registrado puede actualizar una política de inasistencias.
Estas consecuencias deben analizarse cuidadosamente. Algunas son inmediatas y obligatorias; otras son opcionales, externas o pueden ejecutarse después.
18.11 Nombres recomendados
El nombre ayuda a distinguir cada elemento:
- Comandos: Reservar turno, Cancelar turno, Publicar agenda, Registrar pago.
- Consultas: Consultar disponibilidad, Buscar paciente, Listar turnos pendientes, Ver agenda.
- Eventos: Turno reservado, Turno cancelado, Agenda publicada, Pago registrado.
Usar nombres consistentes reduce ambigüedad y mejora la comunicación con el equipo.
18.12 Relación con casos de uso
Un caso de uso puede contener consultas, comandos y eventos. En "Reservar turno", el actor consulta disponibilidad, elige una franja, solicita reservar y finalmente el sistema registra que el turno quedó reservado.
Separar estos elementos permite escribir casos de uso más precisos. También ayuda a identificar qué pasos solo muestran información y cuáles cambian el estado del dominio.
18.13 Relación con pruebas
Esta separación también mejora las pruebas. Para un comando, las pruebas deben verificar reglas, rechazo de casos inválidos y eventos resultantes. Para una consulta, deben verificar que la información devuelta sea correcta. Para un evento, pueden verificarse consecuencias e historial.
Por ejemplo, una prueba puede expresar: dado un turno disponible, cuando se ejecuta Reservar turno, entonces ocurre Turno reservado y el turno queda en estado reservado.
18.14 Tabla de ejemplos
La siguiente tabla muestra ejemplos del dominio de turnos:
| Situación | Comando | Consulta | Evento posible |
|---|---|---|---|
| Reservar atención | Reservar turno | Consultar disponibilidad | Turno reservado |
| Cancelar atención | Cancelar turno | Consultar política de cancelación | Turno cancelado |
| Publicar agenda | Publicar agenda | Ver franjas cargadas | Agenda publicada |
| Registrar asistencia | Registrar atención | Buscar turno confirmado | Turno atendido |
| Confirmar pago | Registrar pago | Consultar saldo | Pago registrado |
18.15 Preguntas para separar conceptos
Estas preguntas ayudan a distinguir comandos, consultas y eventos:
- ¿La operación intenta cambiar el dominio?
- ¿Solo necesita leer información?
- ¿El nombre expresa intención o hecho ocurrido?
- ¿Puede fallar por reglas de negocio?
- ¿Qué evento se produce si la operación tiene éxito?
- ¿Qué consecuencias se disparan después del evento?
- ¿Qué información se necesita antes de tomar la decisión?
18.16 Errores frecuentes
Al trabajar con comandos, consultas y eventos, suelen aparecer estos errores:
- Nombrar comandos como si fueran eventos.
- Registrar eventos aunque el comando haya fallado.
- Hacer que una consulta modifique estado sin que sea evidente.
- No identificar qué reglas validan un comando.
- No registrar consecuencias importantes de un evento.
- Mezclar nombres técnicos con lenguaje del dominio.
- Confundir "lo que se quiere hacer" con "lo que ya ocurrió".
18.17 Qué debes recordar de este tema
- Un comando expresa intención de cambiar el dominio.
- Una consulta lee información sin modificar el dominio.
- Un evento expresa un hecho importante que ya ocurrió.
- Un comando puede fallar; un evento solo debe existir si el hecho ocurrió.
- Las consultas pueden ayudar a decidir, pero no deberían cambiar estado.
- Separar estos conceptos mejora casos de uso, reglas, pruebas y comunicación.
- Los nombres deben usar el lenguaje ubicuo del negocio.
18.18 Conclusión
Distinguir comandos, consultas y eventos permite analizar mejor la dinámica del dominio. Un comando expresa intención, una consulta obtiene información y un evento registra resultado ocurrido. Esta separación evita ambigüedad, ayuda a ubicar reglas y mejora la comprensión de procesos.
En el próximo tema estudiaremos los servicios de dominio, útiles para representar operaciones que no pertenecen naturalmente a una sola entidad.