Explora una compra con EventStorming: identifica acontecimientos, comandos, actores, reglas y excepciones. Aprende a preparar un taller, proponer límites y transformar hallazgos validados en escenarios verificables y una política breve en TypeScript.
El equipo recibe una historia: «Como cliente, quiero confirmar mi pedido para recibirlo».
Desarrollo interpreta que basta con guardar el carrito. Pagos entiende que primero debe completarse el cobro. Almacén espera una reserva de existencias. Atención al cliente sabe que algunos pedidos se cancelan después de pagar porque el producto no estaba disponible.
La historia describe una intención, pero todavía no explica el proceso que el software debe sostener.
Domain Discovery, o descubrimiento del dominio, es el trabajo de comprender decisiones, reglas, acontecimientos y excepciones con las personas que conocen el negocio. No termina al escribir requisitos: continúa cuando aparecen casos que contradicen nuestras suposiciones.
En este artículo exploraremos una compra desde el pedido hasta el despacho. Usaremos un tablero de EventStorming para hacer visibles preguntas antes de convertirlas en código.
Una lista puede pedir crear pedidos, cobrar y despachar. El descubrimiento pregunta qué significa cada acción y qué debe ser cierto para realizarla.
Por ejemplo:
No buscamos reemplazar requisitos por conversaciones interminables. Buscamos obtener información que permita escribir requisitos y modelos más precisos.
Una interfaz solicitada también puede ser una solución anticipada. Si alguien pide «un botón para forzar despacho», conviene averiguar qué situación necesita resolver antes de automatizar ese permiso.
EventStorming es un formato flexible de taller colaborativo para explorar dominios complejos. Permite que participantes con conocimientos diferentes construyan y cuestionen una representación compartida del negocio. Sitio oficial de EventStorming.
No es sinónimo de Domain Discovery. También podemos aprender mediante entrevistas, observación, documentos, ejemplos y prototipos. El taller es una herramienta especialmente útil para reunir perspectivas y detectar desacuerdos.
El nombre oficial se escribe EventStorming, aunque también encontrarás «Event Storming». Aquí mantendremos ambas expresiones reconocibles y usaremos EventStorming al describir la técnica.
No necesitas un broker, un repositorio de eventos ni un proyecto nuevo para comenzar. Los acontecimientos del tablero no son automáticamente mensajes de software.
La documentación de sus creadores distingue tres formatos principales: Big Picture, Process Modelling y Software Design. Los nombres Process-Level y Design-Level suelen utilizarse para referirse a esos niveles de profundidad. Avanscoperta: formatos de EventStorming.
Big Picture: explorar ampliamente una línea de negocio y sus perspectivas, buscando problemas y oportunidades.
Process-Level o Process Modelling: examinar un proceso concreto y sus variantes con más detalle.
Design-Level o Software Design: acercarse a comportamientos, decisiones y límites que orientarán el diseño del software.
No son tres reuniones obligatorias ni una escalera que siempre deba recorrerse completa. Selecciona el alcance según la pregunta que necesitas resolver.
En nuestra tienda, una exploración amplia podría mostrar que pago y preparación concentran incertidumbre. Después profundizaremos en ese recorrido y, finalmente, en una regla pequeña para la preparación.
La propuesta que sigue es un ejercicio didáctico para nuestra tienda ficticia, no una receta universal ni el resultado de un taller real.
Podemos iniciar con:
¿Qué debe ocurrir desde que un comprador presenta un pedido hasta que almacén puede despacharlo, y qué situaciones impiden continuar?
Aclara si estamos describiendo el proceso actual o diseñando uno futuro. Mezclarlos produce acuerdos aparentes: alguien describe lo que hace hoy y otra persona lo que espera que haga el nuevo sistema.
Si se comparan ambos, mantenlos diferenciados.
Incluye personas de ventas, pagos, almacén y atención al cliente, además de desarrollo y producto cuando corresponda.
Un experto del dominio no es solamente quien tiene un cargo formal. Puede ser la persona que sabe por qué una devolución bloqueó una expedición o cómo se reconoce un pago duplicado.
No presupongas que una sola persona conoce todo el proceso. Si falta quien puede responder una pregunta importante, registra esa ausencia como trabajo pendiente.
Usa una superficie amplia, física o digital, accesible para quienes participen. Comprueba que todos pueden leer, escribir y moverse por la representación.
Lleva ejemplos anonimizados de operaciones normales y problemáticas. No hace falta cargar datos personales o secretos en un tablero compartido.
Como propuesta para una primera sesión acotada, reserva tiempo para explorar, recorrer ejemplos y acordar próximos pasos. La duración depende del alcance; una franja en el calendario no garantiza que el dominio quede comprendido.
Para este ejercicio utilizaremos etiquetas de texto. Se pueden acompañar con colores, pero el significado debe seguir siendo legible sin distinguirlos.
[EVENTO] Algo relevante que ocurrió.
[COMANDO] Una intención de cambiar una situación.
[ACTOR] Persona o rol que participa.
[POLÍTICA] Regla que relaciona una situación con una acción.
[LECTURA] Información necesaria para decidir.
[DUDA] Conflicto, incertidumbre o pregunta pendiente.
[EXTERNO] Sistema fuera del alcance explorado.
Las convenciones visuales varían según el formato. Una representación habitual usa eventos naranjas, comandos azules y modelos de lectura verdes; no hace falta introducir todas las categorías desde el primer minuto.
La leyenda anterior es una adaptación pedagógica. Lo importante es acordarla y evitar que una etiqueta haga pasar una suposición por un hecho.
OrderPlaced expresa un hecho: el pedido fue presentado. PlaceOrder expresa una intención: presentar el pedido.
Un comando puede ser rechazado o no completarse. No dibujes su evento esperado como inevitable.
Una política como «cuando haya pago confirmado y reserva vigente, permitir preparar» expresa una regla del negocio. Todavía no decide si se implementará como código síncrono, intervención humana o mecanismo asíncrono.
Un modelo de lectura, por ejemplo «pedidos listos para preparación», aporta información para una decisión. No determina de inmediato una tabla, una vista materializada o una arquitectura específica.
Invita a escribir hechos relevantes en pasado, sin exigir que todos compartan la misma secuencia desde el inicio.
Aparecen:
OrderPlaced Pedido presentado
StockReserved Existencias reservadas
PaymentConfirmed Pago confirmado
OrderPrepared Pedido preparado
OrderShipped Pedido despachado
Si una tarjeta dice «validación», pregunta qué ocurrió realmente. Podría ser «pedido rechazado por dirección incompleta» o un paso técnico que no necesita aparecer en esta escala.
No conviertas esa pregunta en una discusión lingüística interminable. Busca qué decisión o resultado representa el nombre y añade un ejemplo.
Tampoco descartes un acontecimiento porque ocurra fuera del software. La entrega física al transportista puede ser esencial para comprender el despacho.
Para una compra normal, el grupo propone:
OrderPlaced
|
StockReserved
|
PaymentConfirmed
|
OrderPrepared
|
OrderShipped
Esta línea es una hipótesis del recorrido normal. No afirma que reservar siempre deba preceder al pago.
Alguien de pagos explica que algunas operaciones pueden confirmarse antes de conocer la reserva. En vez de corregirlo por comodidad, dibujamos una variante y preguntamos qué condiciones necesita la preparación.
El grupo propone una regla para validar:
Preparar solo cuando el pedido no esté cancelado, exista una confirmación de pago correspondiente y se haya confirmado la reserva requerida.
Ahora hemos descubierto una condición más útil que un orden visual rígido.
La proximidad entre tarjetas no demuestra causalidad. Un hecho puede ocurrir después de otro por la operación habitual sin que exista una dependencia obligatoria.
Profundizamos en una sección del recorrido:
[ACTOR] Comprador
|
[COMANDO] PlaceOrder
|
[EVENTO] OrderPlaced
|
[POLÍTICA] Solicitar reserva para el pedido presentado
|
[COMANDO] ReserveStock
|
[EVENTO] StockReserved
En otra parte:
[LECTURA] Pago confirmado + reserva disponible + pedido no cancelado
|
[ACTOR] Operador de almacén
|
[COMANDO] PrepareOrder
|
[EVENTO] OrderPrepared
El operador necesita información fiable para actuar. Eso abre preguntas: ¿cuándo se actualiza la lectura?, ¿qué ocurre si la reserva vence?, ¿quién comprueba una cancelación que llegó mientras preparaba?
No se resuelven añadiendo flechas. Hay que describir casos y decidir quién responde por ellos.
En vez de preguntar solamente «¿es correcto?», prueba con:
Son preguntas propuestas para el ejercicio. Deben adaptarse a las personas y al proceso real, sin presentar la respuesta que queremos escuchar.
Añadimos tarjetas de incertidumbre:
[DUDA] El pago está confirmado, pero no hay existencias.
[DUDA] La reserva caducó antes de preparar.
[DUDA] El pedido se canceló y después llegó la confirmación de pago.
[DUDA] El operador perdió conexión al registrar el despacho.
Para cada una, identifica qué sabemos y qué falta decidir.
En el primer caso no basta con inventar «devolver dinero automáticamente». Quizá el negocio ofrece espera, sustitución o revisión. Necesitamos responsables, condiciones y un resultado comprensible para el cliente.
En el cuarto, una pérdida de conexión no demuestra que el registro no haya ocurrido. La pregunta de descubrimiento es cómo saber qué sucedió y quién puede comprobarlo, sin diseñar todavía todos los mecanismos técnicos.
Una sesión puede terminar con dudas abiertas. El problema es eliminarlas del dibujo para aparentar que el proceso está completo.
La persona facilitadora ayuda a que las perspectivas puedan aparecer y contrastarse.
Una dinámica posible para nuestra sesión es comenzar con contribuciones individuales breves, agrupar relatos y pedir a otra persona que recorra una operación concreta de principio a fin.
Si una voz domina la conversación, invita explícitamente a quienes realizan el trabajo cotidiano. Si hay desacuerdo, registra las versiones y busca evidencia; una votación no determina cómo funciona realmente el negocio.
Distingue también:
No todo debe resolverse en el taller. Una discusión sobre un algoritmo de ordenación puede apartarse si la pregunta actual es quién puede autorizar un despacho.
El facilitador no utiliza las tarjetas como excusa para decidir por los expertos.
Con varios escenarios revisados, podemos proponer límites.
En Sales, «confirmación» puede describir un compromiso comercial. En Payments, describe evidencia financiera. En almacén, «preparado» habla de una situación física.
Esos cambios de vocabulario, reglas y responsabilidad aportan señales para investigar candidatos a contextos. No basta con contar colores, departamentos o grupos de tarjetas.
También pueden aparecer candidatos a agregados cuando ciertas decisiones necesitan proteger juntas un ciclo de vida. Por ejemplo, el equipo podría estudiar cómo controlar las transiciones del pedido.
Eso no significa que cada comando cree un agregado ni que todo el proceso de compra deba caber en uno. Validamos los candidatos con ejemplos y reglas, no con una extracción automática del tablero.
Los puntos de contacto encontrados pueden alimentar después un Context Map. Las relaciones organizacionales y contratos todavía requieren discusión específica.
Tomemos la hipótesis de preparación y escribamos escenarios:
Dado un pedido no cancelado
y evidencia de pago y reserva correspondientes al pedido,
cuando se evalúa su preparación,
el resultado permite continuar.
Dado el mismo pedido sin evidencia de pago,
cuando se evalúa su preparación,
el resultado indica que falta el pago.
Dado un pedido cancelado,
aunque existan pago y reserva,
la evaluación no permite continuar.
Estos escenarios hacen explícito lo que debemos confirmar con los responsables. No describen todavía transporte, persistencia o permisos.
También necesitamos un contraejemplo: un pago válido para otro pedido no satisface la condición. Añadirlo evita que «hay un pago» sustituya a «está pagado este pedido».
El siguiente fragmento ilustra una evaluación derivada del taller. Los hechos ya se han obtenido y validado mediante fuentes autorizadas. No se consultan contextos externos ni se ejecuta el despacho.
En preparation-assessment.ts:
export interface PreparationFacts {
readonly orderId: string;
readonly cancelled: boolean;
readonly confirmedPaymentOrderId: string | null;
readonly reservedStockOrderId: string | null;
}
export type PreparationAssessment =
| { readonly kind: "READY" }
| {
readonly kind: "BLOCKED";
readonly reason:
| "ORDER_CANCELLED"
| "PAYMENT_NOT_CONFIRMED"
| "STOCK_NOT_RESERVED";
};
export function assessPreparation(
facts: PreparationFacts,
): PreparationAssessment {
if (facts.cancelled) {
return { kind: "BLOCKED", reason: "ORDER_CANCELLED" };
}
if (facts.confirmedPaymentOrderId !== facts.orderId) {
return { kind: "BLOCKED", reason: "PAYMENT_NOT_CONFIRMED" };
}
if (facts.reservedStockOrderId !== facts.orderId) {
return { kind: "BLOCKED", reason: "STOCK_NOT_RESERVED" };
}
return { kind: "READY" };
}
La función es autocontenida como política didáctica. No incluye paquetes externos ni un modelo completo de pedidos.
La evidencia de pago presupone importe y moneda correctos. La evidencia de reserva presupone productos, cantidades y vigencia comprobados. Solo mostramos la correspondencia con el pedido para concentrarnos en la regla descubierta.
READY es una evaluación de los hechos proporcionados, no una autorización durable para preparar en cualquier momento. Antes de aplicar la operación real hay que tratar cambios concurrentes, permisos y vigencia. El tablero ayuda a reconocer esos requisitos; no los implementa.
Si aparecen prioridades distintas entre bloqueos, el orden de las comprobaciones también debe validarse con el negocio.
Un ejemplo de prueba propuesta utiliza las APIs integradas de Node.js y presupone compilación a JavaScript ESM. No se ha ejecutado como parte del artículo.
import test from "node:test";
import assert from "node:assert/strict";
import { assessPreparation } from "./preparation-assessment.js";
test("un pago de otro pedido no permite preparar", () => {
assert.deepEqual(assessPreparation({
orderId: "order-100",
cancelled: false,
confirmedPaymentOrderId: "order-999",
reservedStockOrderId: "order-100",
}), {
kind: "BLOCKED",
reason: "PAYMENT_NOT_CONFIRMED",
});
});
test("una cancelación impide continuar aunque haya evidencia previa", () => {
assert.deepEqual(assessPreparation({
orderId: "order-100",
cancelled: true,
confirmedPaymentOrderId: "order-100",
reservedStockOrderId: "order-100",
}), {
kind: "BLOCKED",
reason: "ORDER_CANCELLED",
});
});
Estas pruebas verifican la decisión con entradas controladas. No prueban que el pago exista o que la reserva siga vigente.
Si los hechos vienen de otros contextos, sus integraciones necesitan contratos y traducciones del consumidor. No se resuelve importando directamente entidades ajenas ni suponiendo transacciones compartidas por HTTP.
No conviertas la foto del tablero en el único resultado. Para esta exploración necesitamos:
Un hallazgo podría registrarse así:
Observación: el operador comprueba pago y reserva antes de preparar.
Regla propuesta: ambas evidencias deben corresponder al pedido.
Pendiente: cómo detectar reserva vencida durante la preparación.
Responsables por consultar: operaciones de almacén y equipo de inventario.
Siguiente paso: revisar un caso real de vencimiento y acordar el comportamiento.
No atribuyas acuerdos a personas que no participaron o no los validaron.
El descubrimiento también puede aportar evidencia estratégica: quizá los errores de selección del producto, y no el despacho, concentran el valor de mejora. Eso orienta qué capacidad investigar primero sin repetir toda la clasificación de subdominios.
Un equipo quiere automatizar acceso a un curso. Un taller revela diferencias entre solicitud de matrícula, matrícula aceptada y acceso habilitado.
El alumnado puede necesitar una aprobación o cumplir requisitos previos. Una tarjeta «usuario registrado» no representa esos hechos.
El aprendizaje es buscar decisiones y excepciones detrás de un estado aparentemente simple, en lugar de implementar un único booleano.
Una aplicación muestra horarios disponibles, pero el personal también reserva espacios por teléfono. El proceso real incluye trabajo fuera del software.
Descubrir esa operación evita construir un sistema correcto solo para los casos que ya eran visibles.
Si el proceso es pequeño y una entrevista con la persona responsable aclara sus reglas, quizá no haga falta un taller amplio. La técnica debe servir a la pregunta, no convertirse en requisito ceremonial.
Cursor, Codex o Claude pueden ayudar con preguntas y borradores, pero no saben por sí mismos cómo funciona una organización concreta.
Antes de la sesión:
Con este alcance y los roles participantes, prepara preguntas sobre decisiones, excepciones y referencias entre operaciones. No inventes el proceso ni presupongas el orden de pago y reserva. Separa preguntas abiertas de hipótesis para contrastar.
Después de la sesión:
Organiza estas notas anonimizadas en hechos observados, reglas confirmadas, propuestas y dudas. Conserva contradicciones y atribución disponible. No completes acuerdos ausentes. Sugiere ejemplos que ayudarían a validar cada incertidumbre.
Al proponer un modelo:
A partir de los escenarios validados, propone candidatos a límites y una política TypeScript pequeña. Explica qué hallazgo justifica cada decisión y qué falta comprobar. No conviertas cada tarjeta en un mensaje, agregado o microservicio.
Las grabaciones, transcripciones y datos operativos deben tratarse con los permisos correspondientes. No es necesario enviar información sensible para pedir ayuda con una estructura de preguntas.
Una respuesta coherente de IA puede seguir siendo una historia inventada. Los responsables del negocio validan su contenido.
Elige un proceso que conozcas: comprar un producto, inscribirse en una actividad o reservar un espacio.
Escribe entre seis y diez acontecimientos en pasado. Para cada uno, anota cómo se sabe que ocurrió y quién puede explicarlo.
Selecciona una decisión y plantea:
Añade el comando, el actor y la información que necesitan. Si lo haces individualmente, marca explícitamente lo que debes validar con otras personas.
Propón una regla y un candidato de modelado. Explica qué ejemplo los apoya y cuál podría demostrar que están mal.
No empieces escribiendo endpoints ni eligiendo infraestructura.
No existe un único tablero correcto para todos los procesos.
En la compra del artículo, un resultado razonable diferencia pago confirmado, rechazo y falta de respuesta; no transforma incertidumbre en fracaso.
La preparación requiere evidencias correspondientes al pedido y considera cancelaciones. Si faltan reglas de vigencia, quedan como preguntas con responsables.
Un candidato a contexto se justifica por diferencias de significado y responsabilidad, no por tener tres tarjetas próximas. Un candidato a agregado se contrasta con decisiones que deben mantenerse coherentes.
La revisión debe poder responder: ¿qué sabemos?, ¿qué suponemos?, ¿quién lo confirmó? y ¿qué ejemplo cambia nuestra interpretación?
Domain Discovery no exige detener todo desarrollo hasta conocer cada excepción. Exige hacer visibles las suposiciones y reducir la incertidumbre importante antes de consolidarla en código.
EventStorming facilita esa conversación cuando reúne perspectivas y permite cuestionar el proceso. El tablero es una herramienta de aprendizaje, no un generador automático de arquitectura.
El siguiente paso es pequeño y verificable: validar una regla, recorrer una excepción o contrastar un candidato de modelo. El descubrimiento continúa cuando esos pasos aportan información nueva.
Cargando tus opciones de aprendizaje…
Cargando conversación…
Integra la colección construyendo una API de pedidos con TypeScript, Express, Zod y SQLite. Incluye los archivos del proyecto, reglas del dominio, eventos, control de versiones, pruebas con Vitest y comandos para ejecutarla y verificarla localmente.
Aprende a orientar agentes de IA con reglas del negocio, límites de contexto y criterios verificables. Un caso en TypeScript muestra cómo preparar instrucciones, proteger Order, diseñar pruebas y revisar cambios sin delegar el criterio arquitectónico.
Compara un monolito modular con una separación de Sales, Payments e Inventory. Diseña contratos en TypeScript y Express y comprende fallos parciales, consistencia eventual, idempotencia, Outbox y Sagas sin introducir infraestructura compleja.