Event Storming y bounded contexts
Cuatro servicios, uno por tabla
El primer diseño de BCPS Bank fue el más intuitivo: mirar el modelo de datos y hacer un servicio por cada tabla importante. ClienteService, CuentaService, TarjetaService y MovimientoService. Limpio, fácil de explicar en una pizarra.
Un año después, el negocio pide algo sencillo: un límite diario de gasto por tarjeta. Tres equipos tienen que coordinar sus despliegues. Y cada transferencia es una conversación de ida y vuelta entre servicios que no se entienden sin los demás.
En el episodio 1 vimos que las fronteras hay que ponerlas donde cambia el significado de las palabras. Este episodio va de cómo se encuentran esas fronteras, con la gente que conoce el negocio, una pared y muchos post-its. Y de por qué el resultado es el mapa de ocho contextos que la serie de eventos daba por hecho desde su episodio 0.
La misma pared, dos cortes
Los dos paneles empiezan con la misma pared: un día de Ana contado en eventos. Pulsa Siguiente paso de la pared para ir construyéndola. Hasta el paso 3 son iguales; a partir de ahí, a la izquierda se corta por sustantivos y a la derecha se aplican las heurísticas de Event Storming. Cuando las dos estén hechas, prueba un cambio (el límite diario) y una operación (una transferencia).
Qué ha pasado
Event Storming en cuatro pasos
Event Storming es un taller: se reúne a quien conoce el negocio y a quien construye el software delante de una pared larga, y se cuenta el dominio con post-its. Tiene un orden y unos colores:
- Caos. Cada uno escribe en naranja los eventos que conoce: cosas que han pasado, en pasado (
CuentaAbierta,PagoAutorizado). Sin orden ni discusión. Sale mucho más de lo que cualquiera sabía por separado. - Ordenar en el tiempo. Los eventos se colocan de izquierda a derecha. Al ordenar aparecen huecos («¿y qué pasa entre la autorización y la liquidación?») y discusiones: ahí está el conocimiento que no estaba escrito.
- Comandos y actores. Delante de cada evento, en azul, lo que lo provoca (
Transferir) y quién (Ana, el comercio, el cierre de mes). - Agregados. En amarillo, qué cosa decide si un comando se acepta: la Cuenta decide si se puede cargar; la Transferencia, en qué punto está. Es la pieza del episodio 4.
Hasta aquí, los dos paneles son iguales. La pared es la misma; lo que cambia es cómo se corta.
El corte por entidades
A la izquierda, alguien subraya los sustantivos y hace un servicio por cada uno. Es el error de «un servicio por entidad», y es tan común porque parece ordenado. Pero fíjate en qué se lleva MovimientoService: la nómina, el cargo de la transferencia, la transferencia iniciada y completada, la evaluación de riesgo. Cinco eventos de cuatro equipos distintos, con cuatro significados de «movimiento», juntos porque comparten un sustantivo.
El corte por lenguaje: cuatro heurísticas
A la derecha, las fronteras se buscan con heurísticas. No son reglas; son preguntas que, repetidas, suelen señalar el mismo sitio:probar en el laboratorio
- Cambio de lenguaje. Cuando la misma persona es «cliente verificado» en un post-it, «titular» en otro y «portador» en otro, hay una frontera. Es el episodio 1 visto en la pared.
- Eventos pivote. Hay eventos después de los cuales la historia cambia de fase y de protagonistas:
CuentaAbierta,TransferenciaCompletada,PagoAutorizado. Suelen marcar el paso de un contexto a otro. - Actores distintos. Ana inicia una transferencia; el comercio autoriza un pago; el cierre de mes genera el extracto. Usuarios distintos, con necesidades distintas, suelen ser contextos distintos.
- Ritmo de cambio distinto. Las reglas de Antifraude cambian cada semana; el libro de movimientos de Cuentas, casi nunca. Si viven juntos, cada ajuste de riesgo obliga a desplegar el libro.
El resultado son siete contextos: Clientes, Cuentas, Transferencias, Tarjetas, Antifraude, Notificaciones y Reporting. Exactamente el mapa de BCPS Bank. Y cuando más tarde llega Fidelización, es un contexto nuevo que solo escucha TransferenciaCompletada, sin tocar ninguno de los demás: el episodio 1 de la serie de eventos, visto desde aquí.
Dónde se nota: el límite diario y la transferencia
Los dos cortes «funcionan» mientras no cambia nada. La diferencia aparece al cambiar algo:
- Un límite diario por tarjeta.probar en el laboratorio Por entidades, el límite es un campo de TarjetaService, lo gastado hoy vive en MovimientoService y la decisión de autorizar necesita a CuentaService: tres servicios, tres equipos, un despliegue coordinado. Por lenguaje, Tarjetas ya lleva los pagos que autoriza: cambia un contexto.
- Una transferencia.probar en el laboratorio Por entidades, la lógica de «transferir» no vive en ningún sitio: MovimientoService la reconstruye preguntando a ClienteService y a CuentaService una y otra vez. Por lenguaje, Transferencias consulta a Antifraude, manda un comando a Cuentas y publica un evento.
La regla que sale: lo que cambia junto debe vivir junto. Un contexto agrupa lo que comparte lenguaje y motivos para cambiar; una entidad solo agrupa lo que comparte un sustantivo.
Bounded context no es microservicio
Una aclaración importante: un bounded context es una frontera de significado, no de despliegue. Puede ser un servicio, varios (Tarjetas podría tener uno para autorizar y otro para liquidar, con el mismo lenguaje) o un módulo dentro de un monolito, con su propio paquete y sus propias tablas. Muchos equipos empiezan con un monolito bien partido en contextos y separan servicios solo cuando lo pide la escala o la organización. Al revés no funciona igual: partir en servicios sin haber encontrado los contextos es cómo se llega al panel de la izquierda.
Criterio
| Pregunta | Si la respuesta es sí |
|---|---|
| ¿La misma palabra significa cosas distintas en dos partes? | Frontera entre ellas |
| ¿Hay un evento después del cual cambian los protagonistas? | Posible frontera en ese evento |
| ¿Lo usan actores distintos, con necesidades distintas? | Posible frontera |
| ¿Cambian a ritmos muy distintos, o por motivos distintos? | Posible frontera |
| ¿Un cambio de negocio típico toca varias partes a la vez? | La frontera está mal puesta: lo que cambia junto debe vivir junto |
Y dos avisos: las fronteras que salen de un taller son una hipótesis, no una verdad; se revisan cuando el negocio cambia. Y no hace falta un taller de tres días para empezar: una tarde con una pared y las personas adecuadas ya da un primer mapa.
En el mundo real
Event Storming lo creó Alberto Brandolini, que lo describe en su libro Introducing EventStorming. Distingue formatos: el big picture (como el de este episodio, para ver todo el negocio y encontrar fronteras), el de diseño de procesos y el de diseño de software, más cerca del código.
Los colores no son decoración: naranja para eventos, azul para comandos, amarillo para agregados (y para actores, en pequeño), rosa para sistemas externos y lila para políticas («cuando pase X, haz Y»). Que todo el mundo use los mismos hace que la pared se lea sola. En remoto se hace con pizarras digitales como Miro o Mural, con plantillas específicas.
Otras técnicas persiguen lo mismo: Domain Storytelling (contar el dominio como historias con actores y objetos) y el Bounded Context Canvas de la comunidad DDD Crew, una plantilla para documentar cada contexto una vez encontrado: su propósito, su lenguaje, lo que publica y lo que consume.
Siguiente episodio
Tenemos siete contextos y uno que llegó después. Pero no viven aislados: Cuentas publica movimientos, Antifraude contesta a Tarjetas, Transferencias habla con el banco de Luis. Cada una de esas relaciones es de un tipo distinto, con consecuencias distintas para los equipos. Y una de ellas se rompe cuando el banco de Luis cambia su API.
Siguiente · Episodio 3 Context mapping y anti-corruption layer El mapa de relaciones de BCPS Bank, los subdominios, y la capa que impide que el modelo de otro banco se cuele en el tuyo.