Dos recetas perfectas — y por qué eso no basta para escalar

Roma y Boston

Roma. Sede de Objectville Pizza Store número 7. Cierre de viernes. Carbonara perfecta: guanciale curado del proveedor Antonelli, pecorino DOP de un afinador del Lazio, huevos de granja, horno de leña Valoriani precalentado a 280°C sobre piedra. La sede lleva tres años cerrando ejercicio en beneficios. La gerente sabe lo que hace. Sus comensales lo saben también.

Boston. Sede 23. Misma carbonara. Pancetta italiana del importador del puerto, parmigiano envejecido del distribuidor que entra todas las semanas, huevos pasteurizados (regulación local), horno Lincoln eléctrico calibrado a 280°C sobre bandeja perforada. Igual de rentable. Igual de buena. Otra gerente, otro proveedor, otra máquina, mismo plato.

Las dos recetas funcionan. En sus sedes, las dos son perfectas.

El problema aparece el día que la central decide abrir 38 sedes nuevas en seis países. La pregunta del consejo es directa: ¿cuál de las dos recetas se replica?

La respuesta correcta es ninguna. Las dos están atadas a cuatro cosas concretas: a un proveedor concreto, a un ingrediente concreto, a una máquina concreta y a una persona que sabe cómo se trabaja en esa cocina. Si Objectville abre en Zúrich, Antonelli no llega allí. La red eléctrica suiza no aguanta el horno de Boston. La gerente de Roma no enseña en alemán. La de Boston tampoco. La receta perfecta es perfecta dentro de su sede. Fuera, no escala.

No es problema de la receta. Es problema de cómo está escrita.

Y aquí entra el corte fino que distingue el Bloque 1 del Bloque 2 de esta serie.

En el Bloque 1 nos preocupamos por escribir la receta — pasar de un Word ambiguo a un artefacto declarativo que negocio escribiera y la plataforma pudiera leer. Ese problema lo dejamos resuelto en la Semana 2. La Semana 5 cerró el restaurante de tres mesas: artesanía perfecta, calidad garantizada, techo incluido. Y allí dijimos que esta semana abriríamos la franquicia.

Lo que muchas series de arquitectura de datos no cuentan es que una receta escrita no basta para escalar. Una receta puede estar perfectamente declarada y aun así estar atada a cuatro cosas que no se replican. Esa es la pregunta del Bloque 2: cuando ya tienes el contrato escrito, ¿cómo lo escribes para que escale?

Y la respuesta tiene un nombre concreto en ingeniería de software desde hace décadas. Llegaremos a ella, pero antes vamos a inventariar las cuatro cosas que atan la receta concreta.

Las cuatro dependencias acopladas

Volved a la receta de Roma. La perfecta. Si la mirás de cerca, la receta no dice solo qué hace una carbonara. Dice también:

1. Quién la ejecuta — la gerente de Roma. La que sabe cuánto tarda el huevo en cuajar al calor residual del plato. La que reconoce, sin medirlo, cuándo el guanciale ha soltado bastante grasa para envolver la pasta. Conocimiento tácito, depositado en una persona concreta.
2. Qué ingrediente usa — guanciale Antonelli, pecorino del Lazio, huevos del proveedor X. Marcas, formatos, orígenes. Si Antonelli cierra mañana, la receta tal como está escrita deja de funcionar. No es que se pueda sustituir el ingrediente — es que la receta no contempla el ingrediente sustituido.
3. Qué máquina la prepara — horno Valoriani, leña, piedra, 280°C. La receta da por hecho que la máquina cocina con perfil de leña. En un Lincoln eléctrico de Boston, los mismos 280°C significan otra cosa. La curva de calor es distinta, la humedad es distinta, el resultado es distinto. La receta de Roma no dice “280°C cocción radiante”: dice “280°C en mi horno”.
4. Qué proveedor de servicios — Antonelli reparte los lunes y los jueves. La franquicia depende de su calendario de distribución, de su capacidad de reposición, de su contrato con Objectville. Cuatro variables fuera del control de la sede pero atornilladas a la receta.

Cuatro dependencias. Una sola receta. Si una falla, el plato no sale.

Y antes de seguir, conviene traducir esto a la conversación que estamos teniendo de verdad — la del dato, no la de las pizzas:

Cuatro dependencias atornilladas en cualquier proyecto de datos serio. Lo notable es que se pueden tener todas resueltas y aun así no escalar. Tu data engineer sabe el sistema, el motor está pagado, la herramienta funciona, el ingestor lleva años corriendo. Y mañana entra un dominio nuevo, y empieza otra vez la cola — porque la siguiente tabla depende de los mismos cuatro nombres concretos.

No es problema de las personas. La gerente de Roma es excelente. El data engineer senior es excelente. Antonelli reparte a tiempo. Oracle 12c funciona. Es problema de diseño: la receta — escrita o no — está acoplada a la mecánica concreta que la materializa.

Esto, dicho en lenguaje arquitectónico, es lo que hace que el equipo central de datos siga siendo el cuello de botella incluso cuando ya escribe contratos en formato declarativo. La Receta de la Semana 2 era el primer paso. No basta con escribirla; hay que escribirla de modo que las cuatro dependencias estén invertidas.

Lo que escala es invertir las cuatro

Lo que escala una franquicia no es flexibilizar las cuatro dependencias para que la receta admita variaciones. Es invertirlas.

Invertirlas significa: la receta deja de hablar de qué uso y empieza a hablar de qué necesito.

La gerente de Zúrich no escribe “horno Valoriani de leña a 280°C piedra”. Escribe “cocción radiante a 280°C, base de cocción que aguante 220°C en la superficie, sin contacto eléctrico directo con la base”. Eso es lo que necesita. La central decide qué horno cumple ese pliego en Suiza, qué proveedor lo distribuye, qué calibrado se ajusta al voltaje local. Si mañana sale un horno mejor, la receta no cambia: la central cambia el adaptador.

La gerente no escribe “guanciale Antonelli”. Escribe “carrillera de cerdo curada al menos 8 semanas, contenido graso entre 60% y 70%, sin nitritos añadidos”. Eso es lo que necesita. La central decide qué proveedor cumple ese pliego en cada país.

Y la persona que ejecuta deja de ser indispensable porque ya no carga el conocimiento tácito en la cabeza. El conocimiento está en la receta. La gerente de Zúrich aprende a leer la receta. La gerente de Tokio también. El conocimiento es transferible porque ya no vive en una persona — vive en el contrato.

Cuando esto se hace bien, la receta escrita en Roma sirve para abrir Zúrich, Tokio, Buenos Aires y Lagos. La receta no se replica con cambios — se replica literalmente. Lo que cambia es la mecánica de detrás: qué proveedor, qué máquina, qué calibrado, quién ejecuta. Y esos cambios no son problema de la receta — son problema de la plataforma central, que es la que se ocupa de que el plato salga igual sea cual sea el continente.

Aquí cae el nombre del principio, una sola vez, sin libro citado, porque cualquiera que haya escrito software lo conoce: esto es inversión de dependencias. No dejes que las piezas de un sistema dependan unas de otras directamente. Haz que todas dependan de un contrato abstracto que sea estable. El contrato es el ancla. Todos tiran de él. Nadie tira del otro en persona.

El ejemplo más familiar — más familiar incluso que cualquier franquicia: imagina que compras un libro de recetas y en la primera página dice “usa el horno Smeg modelo X45, compra el tomate en el Mercadona de la calle Mayor, llama a Ramón que es el proveedor de harina”. No puedes hacerla — no porque no sepas cocinar, sino porque el libro no te da requisitos, te da nombres propios que no controlas. Si Ramón se jubila, el libro se rompe. Eso no es una receta. Es una dependencia disfrazada de receta. La abstracción es el ancla. Nadie tira del otro en persona.

(Para quien venga del mundo del software: mismo principio que OpenAPI/Swagger — el contrato YAML que frontend y backend comparten sin llamarse directamente. Lo mencionamos en la Semana 1.)

En la pizzería, la receta abstracta es ese ancla. En la arquitectura de datos, ese ancla tiene un nombre: Receta, el contrato ejecutable que el dominio escribe y la plataforma lee. Es la pieza que la Semana 2 introdujo y la que en esta semana aprendemos a escribir bien.

La pregunta práctica que cierra esta sección es directa: ¿qué declara el negocio en una Receta y qué resuelve la plataforma? Vamos a verlo con un ejemplo real.

El contrato ejecutable, en concreto

Cojamos una tabla real. Se llama T_POLIZAS. Viene del sistema core de seguros de una entidad regulada. Tiene 25 campos. Todos mezclados en la misma fila: datos del cliente, del mediador, del producto, de la sucursal y de la póliza en sí.

Eso es la foto de la pizza. La analista que lleva quince años en Seguros la mira y ve cinco conceptos. El ingeniero que llega nuevo ve 25 columnas con nombres en código y hace lo que cualquiera haría con una foto: la copia tal cual. Nadie le dio la receta — solo la imagen del resultado.

Y sin la receta, el plato no se puede reproducir: no sabes qué campo cambia con el tiempo y necesita histórico, cuál es una foto de un momento, qué regla de calidad hay que cumplir antes de aceptarlo, ni de qué entidad de negocio es dueño cada campo. La foto no dice nada de eso. Pero la analista sí lo sabe — y el contrato es el sitio donde lo declara.

Ese reconocimiento — que en la pizzería sería “esto es carbonara, con cuatro componentes funcionales: pasta, grasa curada, queso, huevo” — es el primer acto del Domain Ownership. Lo hace el dominio, no la plataforma. La plataforma no lo va a adivinar.

Y aquí entra el contrato. El dominio declara, en un fichero ejecutable, lo que tiene que ser verdad sobre el dato. No declara cómo se materializa; declara qué necesita.

Mirado de cerca, el contrato responde cuatro preguntas — todas en lenguaje del dominio:

¿De quién es esto? Identificación del responsable, dominio, sensibilidad, estado de aprobación, comportamiento de la fuente. Quién es dueño de qué, en términos de gobierno. Esto en el modelo tradicional vive en un Confluence que nadie actualiza. Aquí es obligatorio: la plataforma no genera nada sin estos metadatos.

¿Qué entidades hay? Lista de las entidades de negocio identificadas (Cliente, Producto, Mediador, Sucursal, Póliza) con sus business keys. Y un campo crítico que parece pequeño y no lo es: cada entidad declara si es global — es decir, si es la misma que vive en otros dominios — o local.

Cuando el dominio de Seguros declara que Cliente es global, no inventa un “cliente de seguros” nuevo. Se conecta al Cliente que ya existe en el catálogo común — el mismo que usan Riesgos, Facturación o Reclamaciones. La identidad se comparte; los atributos siguen siendo del dominio. Kernel mínimo, contexto local máximo. Mañana, cuando Siniestros cargue su propia tabla, la plataforma sabrá automáticamente que su Cliente es la misma persona — sin que nadie lo decida en una reunión.

¿Qué atributos tienen y de qué naturaleza son? Aquí el dominio agrupa los campos por entidad y los califica con una palabra que cambia toda la mecánica posterior: la naturaleza. ¿Cambia este dato y necesito histórico? ¿Es una foto de un momento? ¿Es un evento que ocurrió y no se modifica? Tres tipos distintos, tres tratamientos distintos en el almacén. La analista lo sabe porque lleva años viéndolo. El nombre del cliente cambia — necesita histórico. El saldo de hoy es una foto — no se modifica, se añade el del día siguiente. Una transacción ocurrió — no se reescribe, se acumula. La analista lo declara con una palabra. La plataforma deduce todo lo demás.

¿Qué reglas deben cumplirse? Calidad expresada en el idioma del dominio, no en SQL. El NIF tiene formato válido. El scoring está entre 0 y 10. Prima neta = Prima bruta - Reaseguro, con tolerancia de 0,01. Tres niveles: regla a nivel de propiedad, regla a nivel de entidad, regla a nivel de relación. La analista las escribe declarándolas; la plataforma genera los tests y los ejecuta en cada carga.

Esos cuatro bloques juntos forman el contrato. Es JSON, sí — pero el JSON es la representación; no es lo importante. Lo importante es el reparto de responsabilidades:

A la izquierda, lo que el dominio sabe y cuida — la lógica de su negocio. A la derecha, lo que la plataforma encapsula — la mecánica técnica. Las dos columnas están separadas por un contrato declarativo. Exactamente como el libro de recetas que especifica “220°C, 15% de acidez”: si la plataforma cambia de motor mañana, el contrato no cambia. Si el negocio amplía un atributo, la plataforma se adapta sola.

Eso es la Receta cuando está bien escrita. Y bien escrita significa: con las cuatro dependencias invertidas. Sin nombres propios de proveedor, de máquina, de dialecto SQL ni de persona. Solo lo que el dominio necesita que sea verdad.

Cómo se separan los dos planos

Volvamos un momento a la pizzería para clavar el modelo, porque la imagen ayuda al técnico que lo lee y al CDO que lo lee.

Una franquicia bien diseñada — y no hablamos de teoría, esto se ha visto pasar de verdad en negocios físicos cotizados, pero esa historia llegará — funciona porque separa dos planos que la mayoría de cadenas mezclan.

El plano común lo gestiona la central. Es industrializado, mínimo y no negociable. La central se ocupa de las nóminas, del IT, de la distribución, de los contratos con proveedores comunes, del formato de fachada, de la marca. Y de algo crítico: del catálogo canónico de ingredientes, máquinas y procedimientos, expresados en términos abstractos. Cocción radiante a 280°C. Carrillera curada con grasa entre 60% y 70%. Pasta sémola dura. Catálogo, no proveedor concreto.

El plano local lo decide cada sede. Es autónomo, abierto y dueño del contexto. La sede de Zúrich decide qué pizza vende, dónde la coloca, cuántos hace, a qué precio. La sede de Tokio decide igual. La de Roma sigue haciendo carbonara. Pero ninguna de las tres tiene que pelearse con la central por qué horno usar — eso está resuelto en el plano común.

Lo notable es que las dos cosas están a la vez, sin pelearse, porque viven en planos distintos. La central no es flexible — es mínima. La sede no es gobernada — es autónoma sobre lo que es suyo. El gobierno está abajo, en el plano común; la decisión está arriba, en el plano local.

Cuando se mezclan los dos planos, colapsa todo. La cadena que impone planograma desde la central asfixia a sus tiendas y se vuelve cookie-cutter — y muere cuando los hábitos del barrio cambian más rápido que el ciclo de revisión central. La cadena que descentraliza sin estándar común se atomiza en silos: cada tienda hace lo que quiere, ningún cliente reconoce la marca, los proveedores se vuelven imposibles de gestionar.

La separación correcta de los dos planos es exactamente lo que define Domain Ownership en arquitectura de datos. El dominio es dueño de lo que es suyo: qué entidades importan, qué reglas aplica, qué calidad espera, cómo se llama lo que él modela. La plataforma es dueña de lo que es común: todo lo que hace falta para que el contrato del dominio se materialice sin que el dominio lo tenga que construir.

Y las dos cosas conviven sin pelearse porque están separadas por el contrato — la Receta — que cada dominio escribe en su lenguaje y la plataforma resuelve por debajo.

Eso es Domain Ownership ejecutable.

Lo que viene

Para quien opera en sectores regulados — banca, seguros, energía, salud — hay un efecto colateral que conviene anotar: cuando el contrato es ejecutable, el lineage no se busca en un Excel; se lee del contrato que generó la tabla. El owner no se pregunta a un becario; está declarado en el JSON. La sensibilidad de un campo no se documenta en un Confluence; viaja con el campo a lo largo de todo el pipeline. El cumplimiento se vuelve consecuencia del diseño, no proyecto añadido. Cuando llegue la próxima regulación — y va a llegar — no habrá que reescribir el modelo. Habrá que recompilar el contrato.

Pero un contrato no hace nada por sí solo. Alguien tiene que leerlo y materializarlo. Y la pregunta que varios habéis dejado en los comentarios — ¿cómo se implementa técnicamente una despensa? — la contesto la semana que viene cuando entremos al almacén central. Un pilar por vez. Cada pilar, ejecutable. Al final del bloque, un Data Mesh que no colapsa.

La semana que viene entramos al almacén central de Objectville. Y os adelanto el giro: ¿os acordáis de los noodles con salsa de pizza de la Semana 1? Cuando el restaurante se convierte en franquicia, esa pizza con salsa de noodles puede volver. Por otro motivo. Porque cuando hay un brazo robot colocando cajas en el almacén, ninguno de ellos tiene juicio. Si en el estante hay salsa de noodles, te hace la pizza con salsa de noodles. Y la sirve con seguridad académica.

Una cosa más, antes de cerrar. Lo que estamos describiendo en este bloque — la separación de dos planos, la inversión de dependencias, la sede dueña de su contexto — no es teoría. Pasó de verdad, en un negocio físico cotizado, con cifras públicas. Pero esa historia tiene su día propio, y no es hoy. Hoy, el contrato. La que viene, las piezas estructurales que hacen funcionar el almacén central — y por qué sin todas ellas, el brazo robot acaba sirviendo pizza con salsa de noodles.