La identidad a través de los sistemas

Un martes de mayo, Juan Vega compra una camiseta en la tienda del centro. Para la caja registradora, Juan no es Juan: es cliente_1042, el comprador de la camiseta_88. Tres semanas después, ese mismo Juan llega a urgencias con una arritmia. Para el sistema de la clínica no existe ningún cliente_1042; existe paciente_vega, con su episodio y su historia. Y cuando, al mes, Juan paga sus arbitrios, la municipalidad lo conoce por un tercer nombre todavía: contribuyente_77‑3389. Tres sistemas, tres identificadores, una sola persona de carne y hueso que ninguno de los tres sabe que comparte con los demás.

Esa es la grieta que este capítulo cierra. El libro prometió, desde la introducción, que las preguntas servirían de vocabulario común para que sistemas que hoy no se hablan pudieran responder juntos. Pero un vocabulario común no basta. Aunque la tienda y la clínica coincidieran en llamar agente al cable que apunta a una persona, seguirían sin saber que cliente_1042 y paciente_vega son la misma persona. Responder a esa pregunta —¿quién es quién, de verdad, a través de los sistemas?— es lo que llamaremos resolución de identidad, y es el último eslabón que hace posible la promesa cross-dominio.

Identidad no es lo mismo que identificador

Conviene separar dos palabras que el lenguaje cotidiano confunde y que la arquitectura obliga a distinguir. La identidad es la persona real: Juan Vega, un individuo único en el mundo, que existía antes de comprar nada y existirá después de que la camiseta se decolore. La identidad vive en el eje Q quién: es una entidad del modelo, no una cadena de texto. El identificador, en cambio, es el rótulo que un sistema concreto le pega encima para poder referirse a él: cliente_1042 es el identificador que la tienda eligió, y solo tiene sentido dentro de la tienda.

La distinción importa porque los identificadores son locales y arbitrarios. Cada sistema acuña los suyos sin consultar a nadie: la tienda numera a sus clientes en orden de llegada, la clínica usa el apellido, la municipalidad concatena un código tributario. Ninguno es «más correcto» que otro; simplemente son tres nombres privados para una misma persona pública. El error clásico (y la causa de media torre de Babel) es confundir el rótulo con lo rotulado: tratar cliente_1042 como si fuera la persona, en vez de como una flecha que apunta a ella.

La analogía que lo aclara todo: punteros

Quien haya programado en un lenguaje de bajo nivel reconocerá esta situación de inmediato, porque es exactamente la de los punteros. Un puntero no es un objeto: es una dirección, un papelito que dice «el objeto que buscas está allá». Varios papelitos pueden señalar el mismo rincón de la memoria. El objeto es uno; las direcciones que lo apuntan, muchas. Esa asimetría —un referente, varios referentes— es la columna vertebral de este capítulo.

Traduzcamos el modelo entero a ese vocabulario, porque la correspondencia es asombrosamente limpia:

• Cada identificador es un puntero. cliente_1042 no contiene a Juan: apunta a él. Es la dirección que usa la tienda para llegar a la persona.
• Reificar es «tomar la dirección». Cuando en el capítulo 9 convertimos un evento fugaz (una venta, un gol) en un objeto con identidad propia, lo que hicimos fue darle una dirección estable para poder apuntarlo después. Reificar es el operador & del modelo: pasar de «algo ocurrió» a «este algo, al que ahora puedo señalar».
• mismo_que es aliasing de punteros. Dos direcciones, un mismo objeto. Declarar (cliente_1042, mismo_que, persona_vega) es decirle al sistema: «estos dos papelitos llevan al mismo sitio; trátalos como sinónimos».
• El grafo entero es una estructura de punteros. Cada tripleta enlaza nodos por referencia, no por copia. El conocimiento no es una pila de tablas planas: es un tejido de direcciones que se apuntan unas a otras, como un montón de objetos en un heap.

Cómo se resuelve la identidad, en la práctica

Saber que hace falta resolver la identidad es la mitad fácil. La otra mitad es cómo el sistema decide que dos punteros llevan al mismo sitio. Hay tres vías, ordenadas de la más fiable a la más resbaladiza.

Vía 1 · Claves naturales con autoridad externa

La situación ideal: existe un identificador que no es local, sino que lo emite una autoridad reconocida por todos. El DNI de una persona, el RUC de una empresa, un correo verificado, el ISBN de un libro, el IBAN de una cuenta. Cuando dos sistemas registran el mismo DNI, la identidad se resuelve sola: no hay nada que adivinar, porque ambos están citando la misma fuente de verdad externa. La clave natural es, en términos de la analogía, una dirección canónica que todo el mundo acordó usar.

(cliente_1042,  documento_dni, "20148833")   ∈ M(Q, K)   // la tienda lo registró
(paciente_vega, documento_dni, "20148833")   ∈ M(Q, K)   // la clínica también
// misma clave natural ⇒ misma identidad: la resolución es deductiva, no probable

Vía 2 · mismo_que declarado como un hecho más

A veces no hay clave común, pero alguien (un humano, un proceso de conciliación, una migración) sabe que dos identificadores coinciden y quiere dejarlo escrito. El modelo no necesita maquinaria nueva para eso: la identidad compartida se guarda como cualquier otro hecho, una tripleta con el cable mismo_que. Es la elegancia del enfoque: una afirmación de identidad es un dato de primera clase, fechable, atribuible y revisable como cualquier otro.

Porque es un hecho como los demás, puede reificarse cuando importa quién lo afirmó y cuándo (exactamente las razones de reificación del capítulo 9). Una fusión de identidades en un banco no es trivial: conviene saber qué operador la aprobó, con qué evidencia y en qué fecha, por si mañana hay que deshacerla.

Vía 3 · Matching probabilístico

El caso incómodo, y el más frecuente en la vida real: no hay clave común y nadie declaró nada. La tienda guardó «Juan Vega», la clínica «J. Vega Ramos», la municipalidad «Vega, Juan A.». ¿Son el mismo? Probablemente. Pero «probablemente» es una palabra peligrosa en una base de datos. Aquí la identidad se infiere comparando rasgos (nombre, fecha de nacimiento, dirección, teléfono) y calculando una probabilidad de coincidencia. Por encima de cierto umbral, el sistema propone que son la misma persona; por debajo, los deja separados.

El modelo: una persona canónica con identidades colgando

Con las tres vías sobre la mesa, el patrón de modelado es directo. Existe una identidad canónica (un único nodo en Q, persona_vega) y, a su alrededor, los identificadores locales de cada sistema, unidos a ella por mismo_que. Cada sistema sigue usando su rótulo de siempre, sin renunciar a nada; el grafo se encarga de que todos esos rótulos converjan en una sola persona.

(persona_vega,  instancia_de, persona)      ∈ M(Q, K)   // la identidad canónica
(persona_vega,  documento_dni, "20148833")  ∈ M(Q, K)   // su clave natural

(cliente_1042,        mismo_que, persona_vega)  ∈ M(Q, Q)   // alias de la tienda
(paciente_vega,       mismo_que, persona_vega)  ∈ M(Q, Q)   // alias de la clínica
(contribuyente_77_3389, mismo_que, persona_vega) ∈ M(Q, Q)  // alias de la municipalidad

// y los hechos de cada sistema cuelgan de su propio puntero, como siempre:
(venta_001,  comprador, cliente_1042)   ∈ M(O, Q)   // la tienda vendió la camiseta_88
(urgencias_2026_071, paciente, paciente_vega) ∈ M(O, Q)   // la clínica abrió el episodio

Observa el reparto de trabajo. Cada sistema escribe sus hechos contra su puntero, como lo ha hecho siempre, sin coordinarse con nadie: la tienda no necesita saber que la clínica existe. La única tripleta que cruza fronteras es la afirmación de identidad. Resolver un grafo de muchos sistemas no exige reescribir los datos de cada uno: exige tender los hilos mismo_que que faltan. El resto del tejido ya estaba.

Reconciliar que el Juan Vega de la tienda, el de la clínica y el de la municipalidad son uno solo no sirve únicamente para ese Juan. Hecho a escala, es lo que permite el padrón único: cruzar los registros de todas las personas repartidas entre sistemas y contarlas una sola vez, sin duplicados.

No es una decisión numerada: es una convención de fondo

Vale la pena ser explícito sobre el estatus de esto. La resolución de identidad no introduce una regla de diseño nueva al modo de las que hemos ido numerando (no hay aquí ninguna maquinaria que no existiera ya). Es, más bien, una convención fuerte que se desprende de piezas que el lector ya conoce: la entidad del eje Q como referente, el cable como referencia, la reificación como dirección estable. La identidad emerge de juntarlas bien, no de añadir nada.

Por qué esto sostiene toda la promesa del libro

Detente a imaginar la consulta que da sentido a este libro entero: «muéstrame todo lo que el sistema sabe de Juan Vega». Sus compras en la tienda, su episodio en urgencias, sus arbitrios en la municipalidad (tres dominios que nunca fueron diseñados para hablarse) reunidos en una sola respuesta coherente. Esa consulta es la prueba viviente de la interoperabilidad que la introducción prometió. Y es imposible sin resolución de identidad: sin las flechas mismo_que, la pregunta «¿qué sabemos de Juan?» se rompe en tres preguntas que ningún sistema puede juntar, porque ninguno reconoce al Juan del otro.

Un identificador es un papelito que dice dónde mirar; la identidad es lo que encuentras al mirar. El error de toda torre de Babel es confundir el papelito con la persona.La tesis del capítulo

Con esto, la Parte III queda completa: tenemos el hecho atómico, el espacio donde vive, las situaciones que lo enriquecen, la causalidad que lo enlaza y, ahora, la identidad que permite que todo eso cruce de un sistema a otro sin perderse. Lo que sigue es tender la mano a los mundos vecinos (los objetos de la programación, los bits, los grafos, las cadenas de bloques) y mostrar que el modelo no es una isla, sino un puente.