Cuatro áreas, siete equipos

El punto de partida

New Capital Bank se organiza en áreas, y las que mueven clientes y dinero son cuatro: Alta de clientes, Cuentas y pagos, Tarjetas y Fraude. Cada una pide cambios por sus propios motivos. Lo natural es que el software se corte igual: una caja por área.

Debajo están los siete equipos de la etapa Escala, los de Cuatro tipos de equipo: Clientes, Ahorro, Pagos de cuenta y Tarjetas llevan un flujo de negocio; Motor de remuneración, el cálculo de intereses; Plataforma, lo que todos necesitan para desplegar; Facilitación de cumplimiento ayuda a los demás con la regulación.

Cuatro cambios, dos cortes

En la simulación, la fila de arriba son las áreas, la de en medio el software y la de abajo los equipos, con una línea de cada caja de software a su dueño. Lanza cuatro cambios reales con el corte por áreas y mira dónde caen. Después corta por contextos y repite.

Qué ha pasado

Con el corte por áreas, tres de los cuatro cambios caen en Cuentas y pagos. No es casualidad: esa área contiene tres modelos que hablan lenguajes distintos. Uno habla de movimientos y saldos; otro, de operaciones y límites; el tercero, de devengo y abono de intereses. Tiene tres equipos dentro que se pisan cada vez que algo cambia.

Cuando se parte por donde cambia el lenguaje, salen seis contextos: Alta, Cuentas, Operaciones, Remuneración, Tarjetas y Fraude. Cada cambio cae en uno, con un solo dueño. Son las mismas fronteras que aparecieron en la pared del episodio 2, más las que no estaban en el flujo del Bizum.

Y la fila de los equipos guarda dos sorpresas. Pagos de cuenta es dueño de dos contextos: Operaciones y Fraude, porque el antifraude es comprado y lo que el banco mantiene son sus reglas. Y Plataforma y Facilitación de cumplimiento no son dueños de ninguno: no llevan negocio, ayudan a quien lo lleva.

Las áreas son cómo se organiza el negocio; los contextos, cómo se corta el software; los equipos, quién es dueño. Las tres cosas se parecen, pero no coinciden, y no tienen por qué.

Un contexto no es un microservicio

El siguiente malentendido llega enseguida: «entonces, seis contextos, seis microservicios». O peor: «un servicio por cada cosa del dominio», uno para Cliente, otro para Cuenta, otro para Movimiento… Parece aún más ordenado.

Un contexto es una frontera de modelo: dentro, cada palabra significa una sola cosa. Cuántos programas desplegables hay dentro es otra decisión. En la simulación, Operaciones tiene tres servicios (transferencias, Bizum y límites) y Remuneración, uno. Lanza los mismos cambios con los dos cortes.

Cortado por entidades, cada servicio sabe un poco de todo: el interés de una cuenta está repartido entre Tipo, Cuenta y Movimiento, y los titulares, entre siete servicios. Cada cambio de negocio es un despliegue coordinado. Cortado por contextos, el cambio se queda dentro de las fronteras que tienen sentido para el negocio.

Las cuentas conjuntas tocan cuatro contextos y cuatro equipos: Alta (invitar y verificar al segundo titular), Cuentas (una cuenta con dos titulares), Tarjetas (una tarjeta para cada uno) y Fraude (bloquear a uno sin bloquear al otro). Es un cambio grande y cruza fronteras con cualquier corte. Los próximos episodios van de cómo se coordinan esas fronteras.

No hay regla de uno a uno

Lo ideal es que cada equipo sea dueño de un contexto, pero no es una regla: Pagos de cuenta lleva dos contextos pequeños y funciona. Lo que no funciona es lo contrario: un contexto repartido entre dos equipos. Es la ley de Conway del episodio 4 de la serie anterior: si dos equipos comparten un modelo, cada cambio es una negociación.

Para llevarse

• Un bounded context es la parte del software dentro de la cual cada palabra significa una sola cosa y un equipo decide el modelo.
• Se corta por donde cambia el lenguaje y por lo que cambia junto, no por el organigrama ni por las entidades.
• Un contexto no es un microservicio: puede tener uno, varios o ninguno. Lo que no debe tener es dos dueños.