Dominis de dades en arquitectura Data Mesh

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Dominis de dades en arquitectura DATA MESH.

1. El problema que resol

Les arquitectures analítiques monolítiques —un data warehouse o un data lake central operat per un únic equip de dades— topen amb tres límits quan l'organització creix:

• Coll d'ampolla organitzatiu: un sol equip central ha d'atendre totes les peticions de totes les àrees.
• Desconnexió del domini: l'equip central no coneix el significat de les dades que transforma; els errors semàntics són inevitables.
• Manca de propietat: quan una dada és dolenta, ningú no en respon. El productor no se'n fa càrrec perquè «ja ho arreglarà el data lake».

Data Mesh (Zhamak Dehghani, 2019) proposa descentralitzar l'arquitectura i la propietat analítiques cap als equips de domini, aplicant al món de les dades les lliçons del disseny orientat al domini i dels microserveis.

Data Mesh és, primer, un canvi organitzatiu i de responsabilitats, i només després una arquitectura tècnica. Aquest és el punt que més es malinterpreta.

2. Els quatre principis

2.1 Propietat de les dades orientada al domini

Les dades analítiques les posseeix i gestiona l'equip del domini de negoci que les genera i que millor les entén, no un equip central.

Domini (en Data Mesh): àrea de negoci amb límits clars i un equip responsable, que posseeix, gestiona i serveix les seves pròpies dades analítiques com un producte, amb responsabilitat completa sobre el seu cicle de vida —ingesta, model, qualitat, documentació, accés i evolució.

Aquesta és la definició que respon la pregunta d'examen. Un domini no és una carpeta del data lake, ni un esquema de base de dades, ni un data mart departamental gestionat pel centre: és una unitat organitzativa amb propietat i responsabilitat sobre les seves dades.

Tipus de domini: de font (genera dades des dels sistemes operacionals), de consum (les explota per a un cas d'ús) i agregat (combina dades de diversos dominis per crear una visió transversal).

Delimitació: els límits del domini se solen fer coincidir amb els contextos delimitats (bounded contexts) del Domain-Driven Design i amb les capacitats de negoci de l'organització.

Fronteres entre dominis: quan un domini consumeix dades d'un altre no n'hereta l'esquema intern, sinó el contracte de dades (data contract) que aquell publica —l'esquema, els objectius de qualitat i les regles d'evolució—, perquè un canvi al domini font no trenqui els consumidors sense avís. Els identificadors i les dades mestres compartides (client, ciutadà, immoble) es defineixen com a estàndard comú de la malla, no els imposa cap domini concret als altres.

2.2 Dades com a producte (data as a product)

Cada domini publica les seves dades com un producte amb un propietari (data product owner) i uns consumidors. Un producte de dades ha de complir les característiques DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure):

• Descobrible (Discoverable): registrat al catàleg, amb metadades cercables.
• Adreçable (Addressable): identificador únic i estable per accedir-hi.
• De confiança i veraç (Trustworthy): amb SLO (Service Level Objective, objectiu de nivell de servei) de qualitat publicats (frescor, completesa, exactitud) i mesurats.
• Autodescriptiu (Self-describing): esquema, semàntica, exemples i documentació.
• Interoperable: estàndards comuns de format, identificadors i tipus, per poder-lo combinar amb altres.
• Segur (Secure): control d'accés i compliment aplicats de manera nativa.

S'hi afegeixen sovint valuós per si sol i natiu multientorn.

El producte de dades inclou codi, dades i metadades, i la infraestructura que el serveix: no és només un fitxer.

2.3 Plataforma de dades d'autoservei

Una plataforma comuna proporciona als dominis les capacitats tècniques —emmagatzematge, processament, orquestració, catàleg, control d'accés, observabilitat, CI/CD— de manera autoservei, perquè cada domini pugui publicar productes de dades sense dependre d'un equip central i sense haver de ser expert en infraestructura.

Objectiu: reduir el cost cognitiu del domini. Si publicar un producte de dades exigeix conèixer Kubernetes, la descentralització no funciona.

Plans de la plataforma: infraestructura d'utilitat (emmagatzematge, còmput), experiència del producte de dades (crear, publicar, versionar, monitorar) i malla (mesh) supervisora (catàleg global, llinatge, polítiques).

2.4 Govern federat computacional

Un model de govern federat: un comitè amb representació de tots els dominis i de la plataforma acorda les polítiques globals —estàndards d'interoperabilitat, identificadors, seguretat, privadesa, qualitat mínima—, i cada domini decideix la resta.

Computacional vol dir que les polítiques s'implementen com a codi automatitzat a la plataforma, no com a documents que algú ha de recordar complir: validacions d'esquema, comprovacions de qualitat al desplegament, control d'accés declaratiu, etiquetatge automàtic de dades sensibles.

3. Comparació amb altres arquitectures

Data Mesh vs Data Fabric: el Data Fabric és un enfocament tecnològic —una capa d'integració, metadades actives i automatització que unifica l'accés a dades distribuïdes—; el Data Mesh és organitzatiu. No són excloents: es pot fer servir tecnologia de fabric per implementar una malla.

Data Mesh vs Data Lakehouse: el lakehouse és una arquitectura d'emmagatzematge i processament → tema 32; el mesh és un model de propietat i govern. Un mesh es pot construir sobre lakehouses per domini.

4. Implantació

Passos habituals:

1. Identificar els dominis i els seus límits, alineats amb l'estructura de negoci.
2. Designar propietaris de producte de dades a cada domini.
3. Definir els estàndards globals mínims: identificadors, formats, metadades, SLO de qualitat, classificació de sensibilitat.
4. Construir la plataforma d'autoservei de manera incremental, començant pel que més fricció genera.
5. Començar amb pocs dominis i un cas d'ús transversal que demostri el valor.
6. Automatitzar el govern: cada política nova, un control a la plataforma.
7. Formar els equips de domini en enginyeria de dades.

Riscos i condicions de fracàs:

• Descentralitzar sense plataforma: cada domini reinventa la roda i els costos es multipliquen.
• Descentralitzar sense govern: apareixen definicions incompatibles del mateix concepte i la interoperabilitat es perd.
• Equips de domini sense competències ni capacitat de dades: la propietat és nominal.
• Aplicar-ho a una organització petita: el cost del model supera el benefici. Data Mesh no és per a tothom.
• Confondre'l amb una tecnologia: comprar un producte «data mesh» no en fa cap.

5. Aplicació al sector públic

• Els dominis naturals d'un ajuntament: padró i població, tributs, urbanisme, mobilitat, medi ambient, serveis socials, cultura, recursos humans, contractació. Cadascun té ja un responsable funcional clar, cosa que facilita la delimitació.
• Encaix amb el govern de dades existent: el propietari de la dada i el custodi del model DAMA (Data Management Association) (→ tema 31) es corresponen amb el data product owner i l'equip de domini.
• Compliment com a política computacional: la classificació segons l'ENS, la base de licitud del RGPD, els terminis de retenció i les regles d'anonimització es poden implementar com a controls automàtics de la plataforma — que és exactament el que proposa el govern federat computacional.
• Interoperabilitat: els estàndards globals de la malla han de ser compatibles amb l'ENI i amb els vocabularis normalitzats de catàlegs de dades obertes → tema 33.
• Limitació realista: la majoria d'administracions no tenen la maduresa ni la capacitat d'enginyeria de dades distribuïda que el model requereix. Sovint el pas previ raonable és un lakehouse governat amb propietat de domini clara, sense arribar a la malla completa.

Claus d'examen

• «Domini» no és infraestructura. L'única pregunta oficial d'aquest tema distreu amb un servidor, un proveïdor de serveis i un node de xarxa de comunicacions: la resposta sempre és la unitat organitzativa amb responsabilitat sobre les seves dades, mai un element tècnic (TS-TIC 2025, p. 54).

Per recordar

• Data Mesh és un canvi organitzatiu abans que tècnic: descentralitza la propietat de les dades analítiques cap als dominis.
• Domini = àrea de negoci amb límits clars i un equip que posseeix, gestiona i serveix les seves dades analítiques com un producte.
• Quatre principis: propietat orientada al domini · dades com a producte · plataforma d'autoservei · govern federat computacional.
• Un producte de dades és DATSIS: descobrible, adreçable, de confiança, autodescriptiu, interoperable i segur.
• Computacional = les polítiques s'implementen com a codi automatitzat, no com a documents.
• Mesh ≠ Fabric: el fabric és tecnològic i el mesh, organitzatiu. Mesh ≠ Lakehouse: el lakehouse és emmagatzematge; el mesh, propietat i govern.
• Descentralitzar sense plataforma duplica costos; sense govern trenca la interoperabilitat.
• No és per a organitzacions petites.