Bounded contexts y ownership: quién es dueño de qué dato y por qué importa tanto

Hay una pregunta que revela el estado real de la arquitectura de una organización más rápido que cualquier diagnóstico: ¿quién es el dueño del dato “cliente”?

En organizaciones medianas la respuesta suele ser una versión de “depende”. Comercial tiene su base de prospectos. Operaciones tiene su registro de clientes activos. Finanzas tiene su maestro de facturación. Soporte tiene sus contactos. Cada uno tiene una definición ligeramente distinta de qué es un cliente, y cada uno tiene razón dentro de su contexto.

El error no es que existan varias definiciones. El error es no haberlo reconocido explícitamente, y por eso intentar unificarlas en un único registro maestro que nunca termina de satisfacer a nadie.

Contextos delimitados: la idea que resuelve la confusión

El diseño guiado por el dominio aporta un concepto que ordena esto: el contexto delimitado. Un contexto delimitado es un ámbito donde un término tiene un significado preciso y consistente, con un modelo propio y un límite explícito.

“Cliente” en el contexto de suscripción significa una entidad con perfil de riesgo evaluado. “Cliente” en el contexto de cobranza significa una entidad con obligaciones de pago. “Cliente” en el contexto de soporte significa alguien con derecho a atención. Son tres modelos distintos, cada uno correcto en su contexto, y forzarlos a ser uno solo produce un modelo que no le sirve bien a ninguno.

Lo que sí hay que hacer explícito es la relación entre contextos: qué información viaja entre ellos, en qué dirección, con qué contrato y quién es responsable de cada lado.

Ownership: no es un rol, es una responsabilidad concreta

Decir que un equipo es dueño de un servicio o de un conjunto de datos suena a formalidad organizacional. En la práctica significa cuatro responsabilidades concretas.

Definir el modelo. El equipo dueño decide qué significan los conceptos dentro de su contexto y cómo se estructuran.

Autorizar cambios. Cualquier modificación al modelo o a la interfaz pasa por el equipo dueño. Esto no es burocracia: es lo que evita que un cambio hecho por conveniencia de un consumidor rompa a los otros cinco.

Responder por la calidad. Si el dato está mal, el equipo dueño es quien lo repara. No hay una discusión sobre de quién es el problema.

Sostener la interfaz. El equipo dueño mantiene el contrato con quienes consumen, incluida la compatibilidad hacia atrás y el aviso previo ante cambios que rompan.

Cuando esas cuatro responsabilidades no tienen dueño, ocurren cosas específicas y muy reconocibles: los datos se corrigen en el destino en vez de en el origen, cada consumidor construye su propia limpieza, las definiciones divergen silenciosamente y los reportes de dos áreas dan números distintos para lo mismo.

Por qué esto se volvió más urgente con agentes

Un agente que consulta datos internos amplifica cualquier ambigüedad de ownership.

Si un agente consulta el dato “cliente activo” y hay tres definiciones sin un custodio claro, el agente va a usar la que encuentre primero, con total confianza y sin señalar la ambigüedad. La respuesta va a ser coherente, bien redactada y potencialmente incorrecta.

Peor: cuando alguien detecte el error y pregunte de dónde salió ese número, no va a haber a quién preguntarle. El agente consultó una fuente que no tiene dueño, con una definición que nadie autorizó, en un contexto que nadie delimitó.

Esto convierte al ownership de datos en un requisito previo bastante duro para cualquier despliegue serio de agentes sobre información interna. No como buena práctica: como condición para que las respuestas sean defendibles.

Cómo establecer ownership sin un proyecto de gobierno de datos

La versión corporativa de esto es un programa de gobierno de datos de dieciocho meses que produce un catálogo que nadie mantiene. Hay una versión más corta.

Empieza por los diez conceptos que más importan. Cliente, producto, transacción, empleado, proveedor. No los doscientos: los diez que aparecen en la mayoría de las decisiones.

Para cada uno, nombra un equipo dueño. Un equipo, no un comité. Con nombre y apellido de quien responde.

Documenta la definición en el contexto de ese dueño. Qué es exactamente, qué incluye, qué no incluye, cuándo cambia de estado.

Registra los otros contextos donde el término se usa distinto. Sin intentar unificarlos. Solo hacerlos visibles, con su equivalencia.

Define el contrato entre contextos. Qué campos viajan, con qué frecuencia, qué garantías hay.

Ese ejercicio, para diez conceptos, toma unas semanas con las personas correctas. Y produce un artefacto que sirve simultáneamente para tres cosas: alinear a los equipos humanos, orientar el diseño de sistemas y darle contexto confiable a cualquier agente que consulte esos datos.

Qué hacer con las definiciones que ya divergieron

El caso realista no es una organización que empieza de cero. Es una donde cuatro áreas ya tienen su definición de cliente y todas están en uso.

La reacción instintiva es unificar: un proyecto de dato maestro que produzca la definición única y correcta. Ese proyecto tiene una tasa de fracaso alta y un motivo estructural: cada área necesita su definición para operar, ninguna va a aceptar una que le sirva peor, y el resultado es un modelo que satisface el mínimo común denominador y no le sirve bien a nadie.

Hay una secuencia con mejor rendimiento.

Primero, hacer visible la divergencia. Una tabla con las cuatro definiciones, lado a lado, con sus diferencias explícitas: qué incluye cada una, qué excluye, en qué momento considera que alguien pasa a ser cliente. Solo construir esa tabla ya resuelve una parte de las discusiones, porque la mayoría de los desacuerdos sobre números vienen de suponer que se está hablando de lo mismo.

Segundo, decidir cuál es la fuente para cada uso. No cuál es la correcta: cuál se usa para qué. Para reportar al directorio, esta. Para calcular comisiones, aquella. Para segmentar campañas, la otra. La decisión explícita elimina la ambigüedad sin obligar a nadie a abandonar su modelo.

Tercero, definir las equivalencias. Cómo se traduce un registro de un contexto a otro, qué se pierde en la traducción y qué casos no tienen equivalencia. Esta parte es la que permite que los sistemas se integren sin que cada integración reinvente la conversión.

Cuarto, y solo si hace falta, unificar donde el costo de la divergencia sea alto. A veces sí conviene: cuando la divergencia produce errores frecuentes con consecuencia real. Pero es una decisión caso por caso, con costo y beneficio, no un principio general.

Esta secuencia produce en semanas la mayor parte del beneficio que un proyecto de unificación promete en años. Y tiene una ventaja adicional: al hacer visibles las diferencias, con frecuencia se descubre que dos de las cuatro definiciones son en realidad la misma con nombres distintos, lo que reduce el problema antes de intentar resolverlo.

La señal de que está funcionando

Hay un indicador simple de que el ownership se estableció de verdad. Cuando alguien encuentra un dato incorrecto, sabe a quién avisarle sin preguntar.

Si esa pregunta —“¿a quién le digo?”— todavía requiere una conversación de cinco minutos y termina con “creo que a alguien de operaciones”, el ownership existe en un documento y no en la organización.