Cómo identificar bounded contexts
Identificar bounded contexts no es dibujar cajas en un diagrama ni partir el sistema por tablas. Es encontrar las fronteras donde el lenguaje cambia de significado. Esas costuras ya existen en cómo habla el negocio; el trabajo es escucharlas, no inventarlas.
De todos los conceptos de Domain-Driven Design, el de bounded context es a la vez el más importante y el peor entendido. Importante porque es la herramienta que decide dónde van las fronteras de tu sistema. Mal entendido porque casi siempre se confunde con “un módulo”, “un microservicio” o, peor todavía, “un grupo de tablas”. Y cuando lo confundes con eso, terminas trazando fronteras en los lugares equivocados — fronteras que no contienen nada y que solo agregan costo.
La pregunta práctica que casi nadie responde bien es esta: ¿cómo sé dónde empieza un bounded context y dónde termina otro? No se trata de inventar las fronteras. Se trata de descubrir las que el dominio ya tiene.
Un bounded context es una frontera de significado
Antes de buscar fronteras conviene recordar qué es lo que estamos delimitando. Un bounded context no es una frontera de código ni de despliegue: es una frontera de significado. Es la zona dentro de la cual un modelo y su lenguaje son consistentes y válidos.
La clave está en el lenguaje. Dentro de un bounded context, cada término del negocio significa una sola cosa. “Cliente” quiere decir exactamente lo mismo para todos los que trabajan ahí. Fuera de esa frontera, la misma palabra puede significar algo distinto — y eso no es un error a corregir, es la naturaleza del negocio.
Por eso la mejor forma de encontrar bounded contexts no es mirar el código ni la base de datos. Es escuchar cómo habla la gente del negocio. Las fronteras ya están ahí, expresadas en el idioma de la organización. Solo hay que aprender a oírlas.
La señal principal: la misma palabra significa cosas distintas
La pista más confiable de que estás cruzando una frontera de contexto es esta: un mismo término cambia de significado según con quién hables.
Toma la palabra “producto”. Para el equipo de catálogo, un producto es una ficha con nombre, descripción, fotos y categoría. Para el equipo de inventario, un producto es una unidad física en un almacén con una cantidad y una ubicación. Para el equipo de facturación, un producto es una línea con un precio, un impuesto y un código contable. Tres equipos, tres modelos de “producto” radicalmente distintos, todos correctos en su propio mundo.
El instinto del modelador novato es intentar unificarlos en una sola entidad “Producto” que sirva para todos. Es exactamente el error que hay que evitar. Esa entidad universal termina siendo un monstruo con cuarenta campos donde cada equipo usa diez y se estorba con los otros treinta. La frontera correcta es justo donde el significado cambia: catálogo, inventario y facturación son bounded contexts distintos, y cada uno debe tener su propio modelo de producto.
Cuando escuches a dos personas usar la misma palabra y notes que se refieren a cosas diferentes, marca ese punto. Acabas de encontrar una costura del dominio.
Otras señales que delatan una frontera
El cambio de significado del lenguaje es la señal reina, pero hay otras pistas que apuntan en la misma dirección y conviene tener en el radar.
Cambia el conjunto de personas. Cuando un grupo de procesos lo opera y le importa a un equipo, y otro grupo le importa a otro equipo completamente distinto, probablemente hay una frontera entre ellos. Los bounded contexts suelen alinearse con las áreas de responsabilidad de la organización.
Cambian las reglas de negocio. Si las reglas que gobiernan una parte del proceso son independientes de las que gobiernan otra —cambian por razones distintas, en momentos distintos, a petición de gente distinta— esas dos partes pertenecen a contextos diferentes.
Cambia el ritmo de cambio. Dos áreas que evolucionan a velocidades muy distintas, una que se toca cada semana y otra que lleva años estable, raramente pertenecen al mismo contexto. La frontera las protege mutuamente.
La consistencia inmediata deja de ser necesaria. Dentro de un contexto sueles necesitar consistencia fuerte: las cosas tienen que cuadrar al instante. Cuando cruzas a otro contexto, casi siempre te basta con consistencia eventual. El punto donde “puede tardar un poco en reflejarse y no pasa nada” es, muy frecuentemente, una frontera de contexto.
Ninguna de estas señales es definitiva por sí sola. Pero cuando varias coinciden en el mismo lugar, la frontera es real.
Las técnicas para encontrarlas
Las señales te dicen qué buscar; las técnicas te ayudan a hacerlas aflorar de forma deliberada.
La más efectiva que conozco es Event Storming: reunir en una sala (física o virtual) a la gente del negocio y a la gente técnica, y mapear con notas los eventos de dominio en orden temporal — “pedido realizado”, “pago confirmado”, “envío despachado”. Cuando pones todo el flujo en la pared, las fronteras emergen casi solas: aparecen agrupaciones naturales de eventos, y entre esas agrupaciones hay puntos de quiebre donde el lenguaje, la gente o las reglas cambian. Esos quiebres son tus candidatos a bounded contexts.
Otra técnica es escuchar el organigrama y los flujos de trabajo reales, no los oficiales. Cómo se pasan el trabajo los equipos, dónde hay traducciones y handoffs, dónde alguien “manda la información al otro departamento”. Cada handoff entre áreas suele coincidir con un cruce de contexto.
Una tercera, muy concreta, es rastrear el ciclo de vida de un concepto del negocio. Sigue un “pedido” desde que nace hasta que muere. Verás que en el camino deja de ser un “pedido del carrito”, se vuelve un “pedido a producción”, luego un “envío”, luego una “factura”. Cada vez que el concepto cambia de nombre y de dueño, cruzaste una frontera.
Los errores más comunes al trazarlas
Saber qué buscar ayuda; saber qué evitar, todavía más. Estos son los errores que veo una y otra vez.
Partir por datos en lugar de por comportamiento. Agrupar por “todo lo que toca la tabla de usuarios” produce fronteras técnicas, no de dominio. Un bounded context se define por un modelo y un lenguaje coherentes, no por qué tablas comparte.
Buscar la entidad compartida perfecta. El reflejo de unificar “Cliente” o “Producto” en un solo modelo canónico para todo el sistema. Es la antítesis de DDD. La frontera existe precisamente porque ese concepto no es el mismo en todos lados.
Confundir bounded context con microservicio. Son cosas de niveles distintos. El bounded context es una frontera lógica de modelo; el microservicio es una decisión de despliegue. Un contexto puede vivir perfectamente dentro de un monolito modular. Decidir las fronteras de contexto y decidir cómo desplegarlas son dos pasos separados, y conviene no mezclarlos.
Trazar demasiadas fronteras demasiado pronto. Subdividir un dominio que todavía no entiendes bien produce contextos artificiales que tendrás que volver a fusionar con dolor. Ante la duda, fronteras más grandes y menos numerosas; ya las partirás cuando el dominio te muestre dónde duele de verdad.
La frontera correcta se siente distinta
¿Cómo sabes que acertaste? Una buena frontera de contexto tiene una textura reconocible.
Dentro del contexto, las cosas encajan. El lenguaje es consistente, las reglas conviven sin contradecirse, los cambios son locales. Trabajar ahí se siente coherente: todo el mundo entiende lo mismo por las mismas palabras.
En la frontera, la comunicación es explícita y deliberada. Cuando un contexto necesita algo de otro, lo pide a través de un contrato claro, y muchas veces traduce el concepto de un modelo al otro. Esa traducción no es desperdicio: es la evidencia de que la frontera es real y de que cada lado pudo conservar su propio modelo limpio en lugar de contaminarse con el del vecino.
Si en cambio te encuentras peleando constantemente —el mismo término significa cosas distintas dentro del mismo contexto, los cambios de un área rompen otra sin razón aparente, nadie se pone de acuerdo en qué significa una palabra— la frontera está mal trazada. Esa fricción no es casualidad: es el dominio diciéndote que pusiste la línea en el lugar equivocado.
Cierre
Identificar bounded contexts no es un ejercicio de dibujo arquitectónico ni de partición técnica. Es un ejercicio de escucha. Las fronteras no se inventan en una pizarra: ya están presentes en cómo habla el negocio, en dónde la misma palabra cambia de significado, en dónde el trabajo pasa de unas manos a otras.
El trabajo del que modela no es imponer una estructura, sino descubrir la que el dominio ya tiene y hacerla explícita. Empieza por el lenguaje: busca dónde los términos cambian de sentido, dónde las reglas dejan de aplicar, dónde la consistencia inmediata deja de importar. Esas costuras son tus bounded contexts.
Y recuerda que no tienes que acertar a la primera. El entendimiento del dominio madura con el tiempo, y las fronteras correctas se revelan a medida que lo conoces mejor. Lo importante es seguir escuchando.