Title: Desenvolvimento de Software / Data Mesh
Tags: Desenvolvimento_de_Software Resumo
On every note of this deck, unless a note says otherwise:
tldr: - Contexto histórico (modelo centralizado): uma equipe central de TI/dados coleta, trata e serve dados para toda a empresa, gerando:
- distância entre conhecimento do negócio e produção do dado (entregas que não atendem exatamente a necessidade);
- gargalo (fila para atender áreas de negócio);
- surgimento de shadow IT (soluções paralelas em Excel/R/Matlab etc. fora da governança);
- silos e retrabalho (áreas repetem ingestão/transformação sem saber).
- Data Mesh: aplicação de DDD (Domain-Driven Design) em dados; abordagem sociotécnica e descentralizada para dados analíticos (OLAP), onde domínios de negócio viram proprietários e publicadores de “produtos de dados” (frequentemente com consumo via APIs).
- A TI muda de papel: deixa de ser “fábrica central de dados” e passa a prover plataforma, padrões e capacidades estruturantes.
- Não é “sempre melhor”: faz mais sentido para organizações grandes/complexas; em empresas menores pode ser excesso de complexidade.
- Não elimina ETL: o próprio domínio constrói e mantém os pipelines que transformam dado bruto em dado confiável.
- Data quantum: empacota dados + metadados + código + infraestrutura como unidade indivisível do produto de dados.
- 4 pilares do Data Mesh
- Domain Ownership (propriedade por domínio): áreas (ex.: Finanças) são produtoras responsáveis por coletar, tratar e disponibilizar seus dados.
- Data as a Product (dados como produto): dados devem ser fáceis de descobrir e usar, bem documentados, com qualidade e responsáveis claros.
- Self-Serve Data Platform (infra como plataforma): TI fornece uma plataforma integrada de autoatendimento para domínios criarem produtos sem “reinventar a roda” (ex.: Fabric/Databricks).
- Federated Computational Governance (governança federada computacional): regras globais (segurança, interoperabilidade, qualidade, LGPD) definidas por federação (domínios + TI), com execução local e validação/automação pela plataforma.
- Mudanças-chave vs abordagem tradicional
- Organização: centralizada → domínios donos
- Arquitetura: monolítica → distribuída
- Tecnologia: pipeline “separado” → dados+código (data quantum)
- Operação: governança top-down → federada e automatizada
- Prioridade: dado como ativo → dado como produto
- Infraestrutura: fragmentada → plataforma integrada self-service
link: https://documentacao.online/estudos/aezd.html

front: (Ano: 2025 Banca: CESPE / CEBRASPE Órgão: SUSEP Prova: CESPE / CEBRASPE - 2025 - SUSEP - Analista Técnico: - Área: Tecnologia da Informação e Ciência de Dados) O DataMesh adota um modelo centralizado de governança e integração de dados, priorizando a consistência sobre a escalabilidade.
response: Errado
comment: Pessoal, o Data Mesh é a antítese disso. Ele nasce justamente para combater os gargalos dos modelos centralizados. O Data Mesh propõe uma governança descentralizada (mais precisamente, federada) e foca na escalabilidade e na autonomia dos times de domínio. A ideia é que a arquitetura de dados possa crescer junto com a empresa, sem que um time central de TI vire um gargalo para tudo.
title: Data Mesh
Other fields (not shown on cards):
back: Errado - Pessoal, o Data Mesh é a antítese disso. Ele nasce justamente para combater os gargalos dos modelos centralizados. O Data Mesh propõe uma governança descentralizada (mais precisamente, federada) e foca na escalabilidade e na autonomia dos times de domínio. A ideia é que a arquitetura de dados possa crescer junto com a empresa, sem que um time central de TI vire um gargalo para tudo.

front: (Ano: 2025 Banca: CESPE / CEBRASPE Órgão: SUSEP Prova: CESPE / CEBRASPE - 2025 - SUSEP - Analista Técnico: - Área: Tecnologia da Informação e Ciência de Dados) No DataMesh, os dados são tratados como produtos, e cada domínio é responsável por fornecer, manter e documentar seus próprios dados.
response: Certo
comment: Perfeito. Galera, anotem aí: esse é um dos quatro pilares fundamentais do Data Mesh, o "Dados como Produto" (Data as a Product). A mentalidade muda. O time do domínio (ex: Marketing, Finanças, Logística) não é apenas um consumidor de dados, ele passa a ser dono e fornecedor dos seus próprios dados. E ele tem que tratar esses dados como um produto de verdade: tem que ter qualidade, documentação clara, SLA (nível de serviço), ser fácil de descobrir e acessar. A responsabilidade pela qualidade do dado sai de um time central e volta para quem entende do negócio: a própria área de negócios.
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Perfeito. Galera, anotem aí: esse é um dos quatro pilares fundamentais do Data Mesh, o "Dados como Produto" (Data as a Product). A mentalidade muda. O time do domínio (ex: Marketing, Finanças, Logística) não é apenas um consumidor de dados, ele passa a ser dono e fornecedor dos seus próprios dados. E ele tem que tratar esses dados como um produto de verdade: tem que ter qualidade, documentação clara, SLA (nível de serviço), ser fácil de descobrir e acessar. A responsabilidade pela qualidade do dado sai de um time central e volta para quem entende do negócio: a própria área de negócios.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O data mesh é uma aplicação do BDD no domínio de dados.
response: Errado
comment: Opa, cuidado! BDD é "Behavior-Driven Development" (Desenvolvimento Orientado a Comportamento), uma técnica de desenvolvimento de software ágil focada em como o software deve se comportar do ponto de vista do usuário. O Data Mesh se inspira fortemente em outro conceito: o DDD (Domain-Driven Design), ou Desenho Orientado a Domínio. O pilar "Propriedade de Domínio" do Data Mesh é basicamente aplicar os conceitos do DDD (identificar domínios de negócio, contextos delimitados) para a arquitetura de dados
title: Data Mesh
Other fields (not shown on cards):
back: Errado - Opa, cuidado! BDD é "Behavior-Driven Development" (Desenvolvimento Orientado a Comportamento), uma técnica de desenvolvimento de software ágil focada em como o software deve se comportar do ponto de vista do usuário. O Data Mesh se inspira fortemente em outro conceito: o DDD (Domain-Driven Design), ou Desenho Orientado a Domínio. O pilar "Propriedade de Domínio" do Data Mesh é basicamente aplicar os conceitos do DDD (identificar domínios de negócio, contextos delimitados) para a arquitetura de dados

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O data mesh faz uso de uma governança federada, em que cada domínio possui autonomia de tomadas de decisões e há uma entidade de governança central que estabelece padrões e princípios a serem seguidos.
response: Certo
comment: Isso aí, gente. Esse é o pilar da "Governança Computacional Federada". Pensem nesse modelo como um equilíbrio perfeito. Não é uma bagunça onde cada domínio faz o que quer (descentralização pura), e também não é um regime rígido onde um time central manda em tudo (centralização tradicional). No modelo federado, os domínios têm autonomia para gerir e evoluir seus produtos de dados. No entanto, eles devem seguir um conjunto de regras globais (padrões, políticas de segurança, interoperabilidade) definidas por um time central de governança. É o melhor dos dois mundos: autonomia com responsabilidade e padronização.
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Isso aí, gente. Esse é o pilar da "Governança Computacional Federada". Pensem nesse modelo como um equilíbrio perfeito. Não é uma bagunça onde cada domínio faz o que quer (descentralização pura), e também não é um regime rígido onde um time central manda em tudo (centralização tradicional). No modelo federado, os domínios têm autonomia para gerir e evoluir seus produtos de dados. No entanto, eles devem seguir um conjunto de regras globais (padrões, políticas de segurança, interoperabilidade) definidas por um time central de governança. É o melhor dos dois mundos: autonomia com responsabilidade e padronização.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O data mesh possui um princípio que propõe a separação de código e dados dentro dos domínios de negócio, de modo que eles possam variar de modo menos acoplado, e que seu compartilhamento seja feito por APIs.
response: Errado
comment: O Data Mesh, na verdade, propõe unir o código (de transformação, de pipeline, de acesso) aos dados e à infraestrutura que os serve. A ideia é que o "produto de dado" seja uma unidade autocontida, coesa. Pense em um "data quantum" ou um microsserviço de dados: ele encapsula tudo (os dados, o código que os processa, os metadados, as políticas de acesso). O compartilhamento é feito por APIs sim, mas a lógica não é separar código e dados dentro do domínio, e sim encapsulá-los juntos para que o domínio tenha total controle sobre seu produto.
title: Data Mesh
Other fields (not shown on cards):
back: Errado - O Data Mesh, na verdade, propõe unir o código (de transformação, de pipeline, de acesso) aos dados e à infraestrutura que os serve. A ideia é que o "produto de dado" seja uma unidade autocontida, coesa. Pense em um "data quantum" ou um microsserviço de dados: ele encapsula tudo (os dados, o código que os processa, os metadados, as políticas de acesso). O compartilhamento é feito por APIs sim, mas a lógica não é separar código e dados dentro do domínio, e sim encapsulá-los juntos para que o domínio tenha total controle sobre seu produto.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A tecnologia Data Mesh para arquitetura de dados rejeita a ideia de um data lake ou um data warehouse único para todos os domínios.
response: Errado
comment: De fato, o data mesh rejeita a noção de um DL ou DW centralizado, mas o data mesh não é uma tecnologia – é uma abordagem/metodologia sobre arquitetura de dados, tal qual o Agile é uma metodologia sobre gestão de projetos e desenvolvimento de software. Fonte: https://bootcamp.uxdesign.cc/data-mesh-is-not-technology-solution-9d1fbceb2d7d
title: Data Mesh
Other fields (not shown on cards):
back: Errado - De fato, o data mesh rejeita a noção de um DL ou DW centralizado, mas o data mesh não é uma tecnologia – é uma abordagem/metodologia sobre arquitetura de dados, tal qual o Agile é uma metodologia sobre gestão de projetos e desenvolvimento de software. Fonte: https://bootcamp.uxdesign.cc/data-mesh-is-not-technology-solution-9d1fbceb2d7d

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O princípio da "Plataforma de Dados como Self-Service" no Data Mesh visa reduzir a carga cognitiva dos times de domínio, fornecendo ferramentas e abstrações para que eles possam criar e manter seus produtos de dados sem depender de um time central de infraestrutura.
response: Certo
comment: Pessoal, pensem comigo. De que adianta a gente dar a responsabilidade (propriedade de domínio) para o time de Marketing, se para ele publicar um "produto de dado" ele precisar virar um especialista em Kubernetes, redes, segurança e engenharia de dados complexa? Não funciona. Isso iria aumentar a carga cognitiva (o esforço mental) dele, e ele não conseguiria fazer o trabalho principal, que é entender de Marketing. É aí que entra o quarto pilar: a Plataforma Self-Service. Um time central de plataforma cria uma plataforma fácil de usar. Eles fornecem as ferramentas para que o time de domínio possa, com poucos cliques ou comandos simples, criar, monitorar, publicar e manter seu produto de dado. O time de domínio foca no o quê (o produto), e a plataforma cuida de como (a infraestrutura complexa por baixo dos panos). A questão está perfeita.
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Pessoal, pensem comigo. De que adianta a gente dar a responsabilidade (propriedade de domínio) para o time de Marketing, se para ele publicar um "produto de dado" ele precisar virar um especialista em Kubernetes, redes, segurança e engenharia de dados complexa? Não funciona. Isso iria aumentar a carga cognitiva (o esforço mental) dele, e ele não conseguiria fazer o trabalho principal, que é entender de Marketing. É aí que entra o quarto pilar: a Plataforma Self-Service. Um time central de plataforma cria uma plataforma fácil de usar. Eles fornecem as ferramentas para que o time de domínio possa, com poucos cliques ou comandos simples, criar, monitorar, publicar e manter seu produto de dado. O time de domínio foca no o quê (o produto), e a plataforma cuida de como (a infraestrutura complexa por baixo dos panos). A questão está perfeita.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A arquitetura Data Mesh é uma abordagem primariamente tecnológica, focada na implementação de microsserviços e APIs para dados.
response: Errado
comment: O Data Mesh usa tecnologia, como microsserviços e APIs (eles são ótimas ferramentas para construir os produtos de dados), mas ele NÃO é uma abordagem primariamente tecnológica. A Zhamak Dehghani, criadora do conceito, bate muito na tecla de que o Data Mesh é uma abordagem sociotécnica. O que isso quer dizer? Quer dizer que a mudança na organização (o "socio") e na cultura é tão ou mais importante que a tecnologia.
title: Data Mesh
Other fields (not shown on cards):
back: Errado - O Data Mesh usa tecnologia, como microsserviços e APIs (eles são ótimas ferramentas para construir os produtos de dados), mas ele NÃO é uma abordagem primariamente tecnológica. A Zhamak Dehghani, criadora do conceito, bate muito na tecla de que o Data Mesh é uma abordagem sociotécnica. O que isso quer dizer? Quer dizer que a mudança na organização (o "socio") e na cultura é tão ou mais importante que a tecnologia.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Um dos quatro pilares do Data Mesh é a "Propriedade de Domínio" (Domain Ownership), que alinha a arquitetura de dados à estrutura organizacional da empresa, baseando-se em conceitos do Domain-Driven Design (DDD).
response: Certo
comment: Esse é o primeiro pilar e o coração do Data Mesh. O que tínhamos antes? Um modelo centralizado (Data Warehouse ou Data Lake) onde um time de engenharia de dados, lá no centro, tentava cuidar dos dados da empresa inteira (Finanças, Marketing, Logística, RH...). Esse time central virava um gargalo, pois ele não tinha como entender profundamente as regras de negócio de cada área. O Data Mesh inverte isso. Ele pega emprestado o conceito de Domain-Driven Design (DDD) do mundo do software e aplica aos dados. Ele diz: o time de Finanças é o dono dos dados de Finanças. O time de Marketing é o dono dos dados de Marketing. A arquitetura de dados passa a ser distribuída e espelhar a arquitetura do negócio (os domínios). A responsabilidade pelo dado volta para quem mais entende dele.
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Esse é o primeiro pilar e o coração do Data Mesh. O que tínhamos antes? Um modelo centralizado (Data Warehouse ou Data Lake) onde um time de engenharia de dados, lá no centro, tentava cuidar dos dados da empresa inteira (Finanças, Marketing, Logística, RH...). Esse time central virava um gargalo, pois ele não tinha como entender profundamente as regras de negócio de cada área. O Data Mesh inverte isso. Ele pega emprestado o conceito de Domain-Driven Design (DDD) do mundo do software e aplica aos dados. Ele diz: o time de Finanças é o dono dos dados de Finanças. O time de Marketing é o dono dos dados de Marketing. A arquitetura de dados passa a ser distribuída e espelhar a arquitetura do negócio (os domínios). A responsabilidade pelo dado volta para quem mais entende dele.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A interoperabilidade entre produtos de dados no Data Mesh é garantida por meio de padrões globais de governança federada, que definem formatos de comunicação, metadados e esquemas padronizados.
response: Certo
comment: Pessoal, se temos o pilar da "Propriedade de Domínio" (onde cada um cuida do seu), não corremos o risco de virar uma bagunça? O time A publica dados em formato CSV, o time B em Parquet, o time C usa um nome que ninguém entende... E no final, ninguém consegue cruzar dados de áreas diferentes. Viraria o caos. Para evitar isso, temos o pilar da "Governança Computacional Federada". É um modelo de equilíbrio. "Federada" significa que os domínios têm autonomia para criar seus produtos (eles não pedem permissão para o time central para tudo). Porém, eles devem seguir um conjunto de regras globais (os padrões) definidos por um time de governança central. Essas regras são o que a questão descreve: padrões de metadados (para todo produto ser descobrível), formatos de comunicação (APIs), políticas de segurança, etc. Isso garante a interoperabilidade (a capacidade dos produtos "conversarem" entre si) sem matar a agilidade dos domínios.
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Pessoal, se temos o pilar da "Propriedade de Domínio" (onde cada um cuida do seu), não corremos o risco de virar uma bagunça? O time A publica dados em formato CSV, o time B em Parquet, o time C usa um nome que ninguém entende... E no final, ninguém consegue cruzar dados de áreas diferentes. Viraria o caos. Para evitar isso, temos o pilar da "Governança Computacional Federada". É um modelo de equilíbrio. "Federada" significa que os domínios têm autonomia para criar seus produtos (eles não pedem permissão para o time central para tudo). Porém, eles devem seguir um conjunto de regras globais (os padrões) definidos por um time de governança central. Essas regras são o que a questão descreve: padrões de metadados (para todo produto ser descobrível), formatos de comunicação (APIs), políticas de segurança, etc. Isso garante a interoperabilidade (a capacidade dos produtos "conversarem" entre si) sem matar a agilidade dos domínios.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O Data Mesh elimina a necessidade de pipelines de ETL/ELT, uma vez que os dados já são disponibilizados como produtos prontos para consumo analítico diretamente pelos domínios.
response: Errado
comment: Cuidado, gente. O Data Mesh não faz mágica. Os dados brutos (operacionais) raramente nascem prontos para análise. Eles ainda precisam ser limpos, transformados, enriquecidos, agregados. Ou seja, os pipelines de ETL (Extração, Transformação, Carga) ou ELT ainda são necessários. A grande mudança não é a eliminação do ETL, mas sim a mudança de dono e local desse ETL. No modelo antigo (centralizado), existia um grande pipeline de ETL central. No Data Mesh, o pipeline de transformação passa a ser parte integrante do "Produto de Dado". O time de domínio (dono do produto) é ele mesmo responsável por criar e manter os pipelines que transformam seus dados brutos (ex: dados do sistema de vendas) em um produto de dado limpo e confiável (ex: dados de "vendas consolidadas por região"). O ETL não morre, ele é distribuído e encapsulado dentro de cada domínio.
title: Data Mesh
Other fields (not shown on cards):
back: Errado - Cuidado, gente. O Data Mesh não faz mágica. Os dados brutos (operacionais) raramente nascem prontos para análise. Eles ainda precisam ser limpos, transformados, enriquecidos, agregados. Ou seja, os pipelines de ETL (Extração, Transformação, Carga) ou ELT ainda são necessários. A grande mudança não é a eliminação do ETL, mas sim a mudança de dono e local desse ETL. No modelo antigo (centralizado), existia um grande pipeline de ETL central. No Data Mesh, o pipeline de transformação passa a ser parte integrante do "Produto de Dado". O time de domínio (dono do produto) é ele mesmo responsável por criar e manter os pipelines que transformam seus dados brutos (ex: dados do sistema de vendas) em um produto de dado limpo e confiável (ex: dados de "vendas consolidadas por região"). O ETL não morre, ele é distribuído e encapsulado dentro de cada domínio.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A adoção do Data Mesh é recomendada para qualquer organização, independentemente de seu tamanho ou complexidade, por ser uma arquitetura inerentemente superior ao monopólio de dados tradicional.
response: Errado
comment: O Data Mesh foi criado para resolver problemas de escala e complexidade. Organizações muito grandes, com muitos domínios de negócio, que estão sofrendo com os gargalos de um Data Lake ou Data Warehouse centralizado, são as candidatas ideais. Se a sua empresa é pequena ou média, com um time de dados enxuto e pouca complexidade de negócio, implementar um Data Mesh pode ser um "tiro no pé". A complexidade de manter uma plataforma self-service e uma governança federada pode ser muito maior do que o benefício. Nesses casos, o "monopólio" (um Data Warehouse centralizado) pode ser a solução mais simples, barata e eficiente.
title: Data Mesh
Other fields (not shown on cards):
back: Errado - O Data Mesh foi criado para resolver problemas de escala e complexidade. Organizações muito grandes, com muitos domínios de negócio, que estão sofrendo com os gargalos de um Data Lake ou Data Warehouse centralizado, são as candidatas ideais. Se a sua empresa é pequena ou média, com um time de dados enxuto e pouca complexidade de negócio, implementar um Data Mesh pode ser um "tiro no pé". A complexidade de manter uma plataforma self-service e uma governança federada pode ser muito maior do que o benefício. Nesses casos, o "monopólio" (um Data Warehouse centralizado) pode ser a solução mais simples, barata e eficiente.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) No pilar "Dados como Produto", espera-se que cada produto de dado seja tratável, ou seja, que possua características como ser “descobrível”, endereçável, seguro e confiável.
response: Certo
comment: Perfeito. O que transforma um simples "dado" em um "Produto de Dado"? É justamente o que a questão descreve. Não basta o time de domínio "jogar" o dado de qualquer jeito para os outros usarem. Para ser um produto de verdade, ele precisa ter um conjunto de qualidades (às vezes chamado de "Data Product Affordances"): • Descobrível (Discoverable): Eu preciso ter um lugar (como um catálogo de dados) onde eu possa encontrar que aquele produto existe. • Endereçável (Addressable): Eu preciso ter um caminho padrão e único para acessar esse dado (ex: uma API). • Confiável (Trustworthy): Eu preciso confiar no dado. Isso inclui ter metadados claros, SLAs (garantia de atualização) e boa qualidade. • Seguro (Secure): O acesso deve ser controlado por políticas claras. • (E outras como Interoperável, Compreensível, etc.)
title: Data Mesh
Other fields (not shown on cards):
back: Certo - Perfeito. O que transforma um simples "dado" em um "Produto de Dado"? É justamente o que a questão descreve. Não basta o time de domínio "jogar" o dado de qualquer jeito para os outros usarem. Para ser um produto de verdade, ele precisa ter um conjunto de qualidades (às vezes chamado de "Data Product Affordances"): • Descobrível (Discoverable): Eu preciso ter um lugar (como um catálogo de dados) onde eu possa encontrar que aquele produto existe. • Endereçável (Addressable): Eu preciso ter um caminho padrão e único para acessar esse dado (ex: uma API). • Confiável (Trustworthy): Eu preciso confiar no dado. Isso inclui ter metadados claros, SLAs (garantia de atualização) e boa qualidade. • Seguro (Secure): O acesso deve ser controlado por políticas claras. • (E outras como Interoperável, Compreensível, etc.)