En nuestra experiencia la causa rara vez es el modelo. Es que los datos viven centralizados en una plataforma que nadie posee y por cuya calidad nadie responde. El estándar O-AA llega a la misma conclusión por otro camino, y propone algo distinto: que cada dominio de negocio aloje y sirva sus propios datos.
El estándar usa un ejemplo pequeño y demoledor: la palabra «parte».
En el contexto de almacén, una parte tiene un número de parte y existe en distintas cantidades en distintas bodegas. En el contexto de control de calidad, una parte es un objeto físico: cada una se somete a pruebas y sus resultados se guardan por separado.
Si se diseña una sola base compartida para las dos áreas, el modelo se unifica a costa del vocabulario de una de ellas. Hay que renombrar «artículo» como «parte» en control de calidad y buscar otro nombre para lo que ahí se llamaba parte, o al revés. Cualquiera de las dos opciones deja a un área hablando un idioma que no es el suyo.
«La base compartida empezaría a usar un lenguaje propio, lo que puede llevar a problemas de comunicación y a errores.»
O-AA §18.4«La unificación total del modelo de dominio para un sistema grande no va a ser factible ni costeable.»
O-AA §18.4 · Evans 2003Y aquí está la conexión que casi nadie hace: esto no es un problema de datos, es un problema de arquitectura. Es el mismo contexto delimitado del diseño guiado por el dominio, aplicado a la capa de datos. El lago monolítico es una arquitectura por capas disfrazada de plataforma.
«Los datos son solo un modelo de la realidad, no son la realidad. Dependiendo del contexto, el mismo territorio puede representarse con mapas distintos.»
O-AA §18.3Suena filosófico y es operativo: dos áreas pueden tener modelos distintos del mismo hecho y las dos estar bien, siempre que la frontera entre sus contextos sea explícita. El error no es que existan dos mapas — es fingir que hay uno solo.
Por eso el estándar insiste en que la correspondencia entre lo que hay dentro del sistema y lo que pasa en el mundo real sigue importando, y que los criterios de calidad de datos son en su mayoría neutrales a la tecnología. Cambiar de plataforma no arregla un dato mal capturado.
Vienen del mundo de la auditoría y son el piso mínimo. Si su plataforma de datos no puede responder por los cinco, ningún modelo de IA encima va a ser confiable:
| Objetivo | Control |
|---|---|
| Todas las transacciones se registran | Procedimientos que eviten omitir operaciones en los libros |
| Cada transacción es real | Ni transacciones ficticias ni la misma registrada dos veces |
| Está bien valuada | Verificar que los montos asentados son correctos |
| Está en el periodo correcto | Que se apliquen las reglas de negocio que determinan el periodo |
| Está bien asignada | Que se agregue en las cuentas correctas |
El estándar retoma el planteamiento que Zhamak Dehghani publicó en el blog de Martin Fowler: llevar al terreno de los datos lo aprendido en una década construyendo arquitecturas distribuidas a escala.
«En vez de hacer fluir los datos desde los dominios hacia un lago o plataforma de propiedad central, los dominios necesitan alojar y servir sus propios conjuntos de datos de forma fácil de consumir.»
O-AA §18.5 · Dehghani 2019El cambio de fondo es de mentalidad: pasar de un modelo de empujar e ingerir —tradicionalmente por ETL, más recientemente por flujos de eventos— a un modelo de servir y jalar entre todos los dominios.
Contextos delimitados alineados a los dominios que originan el dato. Los ejemplos del estándar: negociación de renta fija, crédito al consumo.
Contextos alineados a los dominios que consumen el dato: contabilidad, liquidez. Que consuman no los vuelve dueños del modelo de origen.
Los hechos de negocio se representan con eventos de dominio que capturan lo que ocurrió en la realidad. El pasado es de lo poco de lo que se puede estar seguro.
Hay un cuarto elemento que suele pasarse por alto y es el que separa un data mesh real de un lago repartido: mentalidad de producto. El dominio que origina el dato lo trata como un producto con consumidores — por ejemplo, ofreciendo instantáneas históricas fáciles de consumir, agregadas en un intervalo que refleje de cerca el ritmo al que ese dominio cambia. Si nadie es dueño del dato como producto, se acaba de mover el monolito de lugar.
El estándar evita recomendar tecnologías —dice explícitamente que el panorama evoluciona demasiado rápido— pero sí fija los requisitos que debe cumplir la solución, que es lo que no cambia:
| Requisito | Para qué |
|---|---|
| Escalar hacia arriba y hacia abajo | Con gracia, no a saltos |
| Auto-recuperarse | Cuando un pico mayor rompa el sistema |
| Regular el flujo (throttling) | Proteger a los sistemas río abajo que no aguantarían el pico |
| Tolerar fallas | Mejorar la resiliencia |
| Ser modular | Facilitar la reutilización y la evolución de los bloques |
| Ser amigable al monitoreo | Para la operación del negocio y de TI, no solo de TI |
Antes de evaluar plataformas, conviene contestar una sola cosa: ¿quién responde por la calidad de los datos que alimentan su caso de uso?
Si la respuesta es «el área de datos», el hueco está abierto y ninguna herramienta lo va a cerrar. Si la respuesta es un dominio de negocio con nombre y apellido —quien origina el dato y vive de que esté bien— entonces sí hay dónde parar.
De ahí en adelante el trabajo se parece mucho al de cualquier partición: descubrir el dominio con los eventos reales, delimitar los contextos de origen y de consumo, y acordar los contratos entre ellos. Es el mismo método que usamos para partir un core, aplicado a los datos. La diferencia es que aquí el incentivo es inmediato: cada dominio que se vuelve dueño de su dato desbloquea los casos de uso que dependían de él.