El pase de la cocina — fachada, emplatado físico y especificaciones que firman el plato

“La cocina es para el cocinero. La carta es para el comensal. Quien confunde las dos no tiene ni cocina ni comensal.”

El pase de la cocina, viernes a las ocho y cuarto

Es viernes por la noche en la sede de Marlene en Chicago. Ocho y cuarto. La cocina ha sacado quince pedidos en los últimos veinte minutos y todavía hay otros nueve en cola. En el pase, perfectamente alineadas, esperan las pizzas para los camareros: tres napolitanas, dos quattro formaggi, una californiana, dos Chicago Deep Dish — y, encima de una de las Chicago, una carta pequeña, doblada en dos, escrita con tinta limpia.

La carta dice cinco cosas: qué pizza es, qué ingredientes lleva la masa (validados con la regla de frescura del producto v4.0), qué alérgeno controlado contiene, qué tiempo de horno ha pasado, qué sede la ha emplatado y la firma. La carta no dice qué versión de la salsa de tomate San Marzano se ha usado, ni cuántos cruces ha hecho el sistema en bodega, ni si la materialización del cliente fidelizado se actualizó hoy a las seis de la mañana o ayer a las once. Esa información existe — está en la cocina, en los albaranes, en los registros del sistema central, en las firmas de los componentes del vault que la sede consume. Está toda. Pero no se sirve al cliente. El cliente no la necesita. El cliente necesita comer.

El camarero coge el plato, lo lleva a la mesa siete. La pareja que ha pedido la Chicago Deep Dish con honey gold no sabe nada de componentes del vault. No sabe que la frescura del producto se calcula con una fórmula que validó el equipo de calidad alimentaria, ni que el puntuación del cliente fidelizado se compone de tres métricas con sus pesos certificados por dirección. Sabe que la pizza está caliente, está en su mesa, y huele bien. Cinco minutos después, está comiendo. Una hora después, paga, deja propina, y se va contento. Vuelve el viernes siguiente.

Eso que acaba de pasar — la pizza emplatada con su carta pequeña, no la cocina, no las salsas base, no el aparato físico de aceleradores que la sostiene — es lo que el consumidor recibe. Y el cuidado con el que la sede emplata es la diferencia entre una cadena que el cliente reconoce y una cadena que el cliente abandona. Esa pizza emplatada es un producto de datos. Y la doctrina técnica que la sostiene es la última pieza del bloque que llevo construyendo — desde el inicio del bloque hasta hoy.

Hoy abro el pase. Tres piezas técnicas. El cuarto pilar de Data Mesh entero — Datos como producto — y la pieza humana que separa una sede que prospera de una que cierra cierran el bloque en la próxima entrega. Hoy entendemos el aparato: cómo se sirve un plato firmado al consumidor.

Vamos por orden.

Eje 1 — patrón Fachada: el pase que aísla al cliente de la cocina

Hay un patrón de diseño de software con tres décadas de cocción en el campo, catalogado por la Banda de los Cuatro (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) en Design Patterns (1994). Se llama patrón Fachada y resuelve un problema que cualquiera que haya tocado un subsistema complejo conoce: cuando tienes muchas piezas, muchos contratos, muchas reglas internas — y consumidores que solo quieren hacer una cosa concreta —, les das una sola puerta. Esa puerta es la fachada. Detrás está toda la complejidad; delante hay una sola interfaz, clara, estable, con su contrato propio. El consumidor no ve la complejidad. La complejidad sigue ahí.

La metáfora es exactamente la del pase de la cocina. Detrás del pase: la cocina con cuarenta dominios, doscientos Satellites, ochenta componentes del vault, cinco capas de aceleradores físicos que vamos a ver en el siguiente eje. Delante del pase: el plato emplatado con su carta pequeña. La fachada es el pase.

Trasladado al modelo de datos que hemos venido construyendo, una fachada es una vista por caso de uso, con su contrato explícito:

• Identidad del consumidor: quién la consume — un equipo de marketing, un sistema de fraude, un panel de dirección, un consumo regulatorio.
• Contrato de salida: qué columnas devuelve, con qué tipos, con qué semántica. Estable. Versionada.
• Origen declarado: qué componentes del vault consume, qué Satellites toca por debajo, qué reglas de calidad firma el plato.
• Garantías: qué propiedades cumple — frescura máxima, latencia máxima, completitud, exactitud.
• Trazabilidad heredada: si un auditor pregunta “qué versión del cálculo había detrás de esta vista el 14 de marzo”, la respuesta está pegada al artefacto, no en registros.

Cuando un sistema consumidor — el motor de fraude, por ejemplo — necesita saber el puntuación consolidado del cliente, no consulta directamente al Hub Cliente, ni al Satellite de fidelización, ni al componente del vault de puntuación. Consulta una fachada que se llama “puntuación consolidado por cliente — vista de fraude v2.1”. Esa fachada firma su carta: “esta vista te entrega puntuación, fecha de cálculo, frescura del cálculo, alertas asociadas. Garantizo latencia menor de 30 segundos. Detrás uso los componentes del vault A, B, C, en sus versiones tales. Si cualquiera de los tres rompe su contrato, yo te aviso primero. Si tú quieres una versión nueva, dímelo y la negociamos.”

La fachada hace cuatro cosas a la vez:

1. Aísla al consumidor de la complejidad de la cocina. El motor de fraude no necesita saber que hay 47 Satellites del Hub Cliente, ni que hay 12 componentes del vault versionados, ni que la materialización de fidelización se actualiza cada media hora. Solo necesita el puntuación y el contrato de la fachada.
2. Estabiliza el contrato del consumo aunque la cocina cambie. Si mañana el componente del vault de fidelización sube de v1.5 a v1.6, la fachada puede absorber el cambio internamente sin tocar el contrato hacia fuera. El motor de fraude sigue consumiendo igual. Si la migración requiere un cambio de contrato visible, la fachada negocia explícitamente — no se cuela.
3. Concentra el gobierno del consumo en un punto identificable. Cuando llega un auditor preguntando por la trazabilidad de un caso, la respuesta no es “hay que reconstruir 200 SQLs”. La respuesta es “esta consulta entra por la fachada X. Esta es su carta. Estos son los componentes del vault que firma. Estos son los Satellites que tocan.” Trazabilidad en una conversación.
4. Hace explícito quién es el cliente del dato. Cada fachada tiene un consumidor identificado. Y por tanto cada fachada tiene un dueño que la mantiene — el dominio que la firma. Eso es lo que convierte el dato en producto, no en subproducto. (El pilar entero — datos como producto — y cómo el dominio se hace responsable cierra en la entrega siguiente.)

“Si la cocina es la complejidad y el comensal el sentido del trabajo, la fachada es lo único que un cliente toca. Por eso hay que cuidarla más que la cocina.”

Lo que un consumidor ve es la fachada. Lo que un consumidor consume es la fachada. Lo que un consumidor recuerda es la fachada. La cocina, por compleja, certificada y bien construida que esté, no se sirve. Se respeta. Se mantiene. Se cuida. Pero no se sirve.

Y aquí entra la pregunta operativa que cualquiera que haya tocado dato a gran volumen tiene en mente desde el pilar anterior: si detrás de la fachada hay un aparato grande, cómo se asegura que la fachada es rápida. La respuesta es la familia entera de aceleradores que llevamos prometiendo desde la entrega anterior.

Eje 2 — La familia del emplatado físico: tablas PIT, tablas puente y materializaciones (rendimiento puro, sin lógica)

Al cerrar el punto óptimo del abierto/cerrado dejé dos reglas de modelado — agrupar por cadencia, limitar profundidad de ensamblaje — y prometí que la familia entera del rendimiento físico la trataría hoy. Aquí está. Y empiezo recordando la frontera que abrimos en la entrega anterior porque es lo que hace que todo lo siguiente tenga sentido:

Las tres piezas físicas tienen una propiedad común que las hace fundamentalmente distintas del vault de negocio: no deciden nada que el negocio tuviera que decidir. Son aceleradores transparentes. Si las borras todas, el resultado del negocio no cambia — solo cambia la velocidad. Esa propiedad es lo que las pone en la capa de servir, no en la de modelado.

Tablas PIT (punto en el tiempo)

Imagina que un consumidor frecuente — un panel de dirección, un sistema regulatorio — pregunta a diario “¿cuál era el estado del cliente Pepe el último día de cada mes durante el último año?”. Esa consulta, sin más ayuda, exige al sistema reconstruir el estado bi-temporal del cliente para 12 fechas distintas, cruzando los Satellites con sus rangos de validez. En volumen grande, eso pesa.

Una tabla PIT es una tabla auxiliar que precalcula, para una entidad concreta, los estados en una fecha concreta más consultados. Para cada cliente, para cada fin de mes, una fila con punteros a los Satellites vigentes ese día. La consulta del panel pasa de tener que reconstruir los rangos de validez en cada llamada a hacer una lectura directa de la tabla PIT.

Lo importante: la tabla PIT no cambia el resultado. Solo lo precalcula. Si la borras, el sistema sigue calculando lo mismo, solo que más lento. No hay lógica de negocio dentro de la tabla PIT — solo punteros. Es vocabulario canónico DV 2.0, descrito por Linstedt y todo el ecosistema serio (Scalefree, AutomateDV, dbt vault) la industrializa.

Tablas puente

Hay consultas que cruzan varios Hubs vía múltiples Links. “Para cada cliente, su sede de origen, sus productos contratados, y su asesor asignado” — eso son cuatro Hubs unidos por tres Links. Sin ayuda, son varios cruces profundos cada vez que la consulta se ejecuta.

Una tabla puente es una tabla auxiliar que precalcula el camino frecuente entre Hubs. Una fila por combinación cliente-sede-producto-asesor, con sus claves canónicas listas para unir. La consulta pasa de tener que recomponer el camino cada vez a leer directamente de la tabla puente.

Lo importante de nuevo: la tabla puente no cambia el resultado. Solo precalcula el camino. Si la borras, los datos siguen ahí, solo que la consulta tarda más. No hay lógica de negocio: solo claves canónicas combinadas. También vocabulario canónico DV 2.0.

Materializaciones selectivas

La forma más simple del emplatado físico: una vista frecuente del negocio se calcula una vez al día (o cada hora, o cada minuto, según se necesite) y se cristaliza en una tabla. Las consultas leen la tabla, no recalculan la vista cada vez.

Lo importante por tercera vez: la materialización no cambia el resultado. Solo lo cristaliza. Y aquí toca decir algo claro porque es donde más se confunden las capas: no se materializa para esconder lógica, se materializa para abaratar la lectura de algo que el negocio consume a diario. Si necesitas materializar para poder ofrecer una garantía de latencia que la fachada firma, materializa. Si materializas para ahorrarte una decisión que tendrías que tomar en el modelado — “meto este cálculo en la materialización porque es más fácil que crear un componente del vault” —, estás creando un componente del vault disfrazado sin firma, sin versión, sin trazabilidad. Y eso es el camino del modelo ingobernable. La frontera es de sentido común técnico, pero hay que decirla.

Por qué la familia entera vive aquí

Las tres piezas — tablas PIT, tablas puente, materializaciones — son infraestructura del pase. Existen para que la fachada pueda firmar latencia razonable sin recomputar todo desde cero cada vez. Sin ellas, una fachada que cruza varios Hubs y varios componentes del vault sería lenta. Con ellas, la fachada es rápida sin pagar lógica duplicada. Y por eso son emplatado, no modelado: existen para servir, no para decidir.

“El vault de negocio decide. Las tablas PIT y puente aceleran. La fachada firma. Confundir las tres es la receta del modelo ingobernable. Distinguirlas con nitidez es lo que permite que el aparato físico crezca sin que el gobierno se diluya.”

Y eso conecta con la siguiente pieza, porque la fachada no es solo abstracción — es también firma de calidad. Y la firma necesita un lenguaje propio.

Eje 3 — patrón Especificación: las reglas de calidad como objetos evaluables

Cuando la fachada entrega el plato al consumidor, firma una garantía. Esa garantía no es un PDF colgado en la documentación interna — es un objeto ejecutable. Eric Evans le dio nombre técnico canónico en Domain-Driven Design (2003): el patrón Especificación es, sencillamente, un predicado evaluable. Toma un objeto, evalúa si cumple unos criterios, devuelve verdadero o falso — y, opcionalmente, devuelve el detalle de qué criterios cumple y cuáles no. La especificación no es una documentación de calidad: es una pieza de código que se puede ejecutar y que se compone con otras. “Cliente válido para esta fachada” puede ser una especificación compuesta por “cliente activo” Y “cliente identificado fiscalmente” Y NO “cliente bloqueado por cumplimiento normativo”. Cada uno de los tres es una especificación primitiva. La compuesta se construye combinándolas con operadores lógicos.

Aplicado al emplatado del dato:

• Cada fachada declara las especificaciones que firma. La fachada “puntuación consolidado por cliente — vista de fraude v2.1” puede firmar tres especificaciones: frescura del cálculo menor de 24 horas, completitud del 98 por ciento mínimo, exactitud del componente del vault subyacente certificada en el último despliegue.
• Las especificaciones se evalúan en cada lectura — o en bandas de tiempo configuradas — y producen un resultado. Ese resultado se devuelve junto con el dato. El consumidor no recibe solo la cifra; recibe la cifra con su firma.
• Cuando una especificación falla, el plato no sale al pase. La fachada puede tomar tres caminos: (1) entregar el dato con un aviso explícito “este plato sale con la especificación de frescura caída”, (2) entregar el dato anterior válido con la fecha de la última firma plena, (3) bloquear el consumo y devolver un error firmado. La decisión la toma el dueño de la fachada — el dominio.

Esto es lo que en el Bloque 1 llamábamos “reglas de calidad como objetos, no como comentarios en SQL”. Es lo mismo, ahora con su nombre técnico canónico — Eric Evans, 2003 — y con el papel exacto que cumple en el aparato: firmar el plato antes de que llegue al cliente.

La diferencia entre una organización que tiene calidad y una organización que dice tener calidad se ve aquí. Cuando la calidad son comentarios en documentación interna, las reglas se desfasan en seis meses y nadie lo nota hasta que el regulador pregunta. Cuando la calidad son especificaciones evaluables firmando cada fachada, la divergencia entre la regla y la realidad es imposible — porque la regla es la ejecución. Si la regla no se cumple, el sistema lo dice. Si la regla cambia, el sistema lo refleja en el siguiente despliegue. La documentación es viva — concepto que ya apareció antes en el bloque — porque el código es la documentación.

“Una regla de calidad que no se evalúa no es una regla — es un deseo. La diferencia entre una franquicia que el regulador certifica y una que no, es si las reglas están en código o están en PowerPoint.”

Y eso conecta directamente con el cuarto pilar de Data Mesh — Datos como producto — que es donde todo lo de hoy aterriza. Pero el pilar entero, con su asimetría operable y su pieza humana, es para la entrega siguiente.

Lo que viene

Hoy abrimos el pase: fachada, emplatado físico sin lógica de negocio, especificaciones que firman antes de servir.

Falta quién decide qué emplatar — el cuarto pilar entero — y la pieza humana que llevo guardando: Brooklyn, la mesa del barrio, lo que una cadena puede matar sin querer.

En el próximo artículo: síntesis en una sola cosa.

Hasta entonces.