Domínios de dados

A malha de dados, no fundo, baseia-se na descentralização e na distribuição da responsabilidade aos domínios. Se você realmente entende essa parte do negócio, está melhor posicionado para gerenciar os dados associados e garantir sua precisão. Este é o princípio da propriedade de dados orientada para o domínio.

Para promover a propriedade de dados orientada a domínio, você precisa primeiro fazer uma decomposição de sua arquitetura de dados. O fundador da malha de dados, Zhamak Dehghani, promove a abordagem Domain-Driven Design (DDD) para o desenvolvimento de software como um método útil para ajudá-lo a identificar seus domínios de dados.

A dificuldade com o uso do DDD para gerenciamento de dados é que o caso de uso original do DDD era a modelagem de sistemas complexos em um contexto de desenvolvimento de software. Ele não foi originalmente criado para modelar dados corporativos e, para profissionais de gerenciamento de dados, seu método pode ser abstrato e técnico. Muitas vezes também há uma falta de compreensão do DDD. Os profissionais acham suas noções conceituais muito difíceis de entender, ou tentam projetar exemplos de arquitetura de software ou programação orientada a objetos em seu cenário de dados. Este artigo fornece orientação pragmática e vocabulário claro para que você possa entender e usar o DDD.

Design orientado por domínio

Introduzido por Eric Evans, o Domain-Driven Design é um método de apoio ao desenvolvimento de software que ajuda a descrever sistemas complexos para organizações maiores. O DDD é popular porque muitas de suas práticas de alto nível afetam as abordagens modernas de desenvolvimento de software e aplicativos para coisas como microsserviços.

O DDD diferencia entre contextos, domínios e subdomínios limitados. Domínios são espaços problemáticos que você deseja abordar. São áreas onde conhecimento, comportamento, leis e atividades se unem. Você vê acoplamento semântico em domínios, dependências comportamentais entre componentes ou serviços. Outro aspeto dos domínios é a comunicação. Os membros da equipe devem usar um idioma compartilhado por toda a equipe para que todos possam trabalhar de forma eficiente. Essa linguagem compartilhada é chamada de linguagem ubíqua ou linguagem de domínio.

Os domínios são decompostos em subdomínios para melhor gerir a complexidade. Um exemplo comum disso é a decomposição de um domínio em subdomínios que correspondem, cada um, a um problema de negócios específico, conforme mostrado em Operacionalizar malha de dados para IA/ML.

Nem todos os subdomínios são iguais. Você pode, por exemplo, classificar domínios como principais, genéricos ou de suporte. Os subdomínios principais são os mais importantes. São o molho secreto, os ingredientes, que tornam uma organização única. Os subdomínios genéricos são inespecíficos e normalmente fáceis de resolver com produtos prontos para uso. Os subdomínios de suporte não oferecem vantagem competitiva, mas são necessários para manter uma organização funcionando e geralmente não são complexos.

Contextos limitados são limites lógicos (contexto). Eles se concentram no espaço da solução: o design de sistemas e aplicações. É uma área onde o alinhamento do foco no espaço da solução faz sentido. Dentro do DDD, isso pode incluir código, designs de banco de dados e assim por diante. Entre os domínios e contextos limitados, pode haver alinhamento, não há nenhuma regra rígida ligando os dois. Os contextos limitados são técnicos por natureza e podem abranger vários domínios e subdomínios.

Recomendações de modelagem de domínio

Se você adotar a malha de dados como um conceito para democratização de dados e implementar o princípio de propriedade de dados orientada a domínio para aumentar a flexibilidade, como isso funciona na prática? Como pode ser uma transição da modelagem de dados corporativos para a modelagem de projeto orientada por domínio? Que lições você pode tirar do DDD para o gerenciamento de dados?

Faça uma decomposição empresarial funcional dos seus espaços problemáticos

Antes de permitir que suas equipes operem seus dados de ponta a ponta, observe o escopo e entenda os espaços problemáticos que você está tentando resolver. É importante fazer este exercício primeiro antes de entrar nos detalhes de uma implementação técnica. Quando você define limites lógicos entre esses espaços problemáticos, as responsabilidades se tornam mais claras e podem ser melhor gerenciadas.

Observe a arquitetura do seu negócio ao agrupar os espaços problemáticos. Dentro da arquitetura de negócios, existem capacidades de negócios: habilidades ou capacidades que uma empresa possui ou troca para alcançar um propósito ou resultado específico. Essa abstração agrupa dados, processos, organização e tecnologia em um contexto específico, em alinhamento com as metas e objetivos estratégicos de negócios da sua organização. Um mapa de capacidade de negócios mostra quais áreas funcionais parecem ser necessárias para cumprir sua missão e visão.

Você pode visualizar a decomposição de capacidade de uma empresa fictícia, Tailwind Traders, no modelo a seguir.

A Tailwind Traders precisa dominar todas as áreas funcionais listadas no Mapa de Capacidade de Negócios para ser bem-sucedida. Os Tailwind Traders devem ser capazes de vender bilhetes como parte dos Sistemas de Gestão de Bilhetes Online ou Offline, por exemplo, ou ter Pilotos disponíveis para pilotar aviões como parte de um Programa de Gestão de Pilotos. A empresa pode terceirizar algumas atividades, mantendo outras como o núcleo de seu negócio.

O que você observará na prática é que a maioria das pessoas está organizada em torno das capacidades do negócio. As pessoas que trabalham na mesma capacidade de negócio partilham o mesmo vocabulário. O mesmo se aplica às suas aplicações e processos, que normalmente estão bem alinhados e estreitamente ligados com base na coesão das atividades que suportam.

O mapeamento de recursos de negócios é um ótimo ponto de partida, mas sua história não termina aqui.

Mapeie os recursos de negócios para aplicativos e dados

Para gerenciar melhor sua arquitetura corporativa, alinhe seus recursos de negócios, contextos limitados e aplicativos. É importante seguir algumas regras básicas ao fazê-lo.

Os recursos de negócios devem permanecer no nível de negócios e permanecer abstratos. Eles representam o que sua organização faz e segmentam seus espaços problemáticos. Quando você implementa um recurso de negócios, uma realização (instância de capacidade) para um contexto específico é criada. Vários aplicativos e componentes trabalham juntos dentro desses limites em seu espaço de solução para oferecer valor comercial específico.

Os aplicativos e componentes alinhados com um determinado recurso de negócios permanecem dissociados dos aplicativos que estão alinhados com outros recursos de negócios, porque eles atendem a diferentes preocupações de negócios. Contextos limitados são derivados e exclusivamente mapeados para recursos de negócios. Eles representam o limite de uma implementação de capacidade de negócios e se comportam como um domínio.

Se as capacidades de negócios mudam, os contextos limitados mudam. Você de preferência espera um alinhamento total entre domínios e contextos limitados correspondentes, mas como você aprenderá em seções posteriores, a realidade às vezes difere do ideal.

Se projetarmos o mapeamento de capacidade para Tailwind Traders, limites de contexto delimitados e implementações de domínio podem ser semelhantes ao diagrama a seguir.

Neste diagrama, o gerenciamento de clientes é construído com base na experiência no assunto e, portanto, sabe melhor quais dados servir para outros domínios. A arquitetura interna do gerenciamento de clientes é dissociada, de modo que todos os componentes do aplicativo dentro desses limites podem se comunicar diretamente usando interfaces e modelos de dados específicos do aplicativo.

Produtos de dados e padrões claros de interoperabilidade são usados para formalizar a distribuição de dados para outros domínios. Nesta abordagem, todos os produtos de dados também se alinham com o domínio e herdam a linguagem ubíqua, que é uma linguagem construída e formalizada acordada pelas partes interessadas e designers do mesmo domínio, para atender às necessidades desse domínio.

Domínios extras de realizações de vários recursos

É importante reconhecer ao trabalhar com mapas de recursos de negócios que alguns recursos de negócios podem ser instanciados várias vezes.

Como exemplo, a Tailwind Traders pode ter várias realizações (ou implementações) localizadas de "manuseio de bagagem e itens perdidos". Suponha que uma linha de seu negócio opera apenas na Ásia. Neste contexto, "manuseio de bagagem e itens perdidos" é uma capacidade que é cumprida para aviões relacionados à Ásia. Uma linha de negócio diferente poderia visar o mercado europeu e, neste contexto, é utilizada outra capacidade de "assistência a bagagem e artigos perdidos". Esse cenário de várias instâncias pode levar a várias implementações localizadas usando diferentes serviços de tecnologia e equipes separadas para operar esses serviços.

A relação entre a capacidade de negócios e as instâncias de capacidade (realizações) é um-para-muitos. Por causa disso, você acaba com (sub-) domínios extras.

Encontre recursos compartilhados e fique atento aos dados compartilhados

A forma como você lida com os recursos de negócios compartilhados é importante. Normalmente, você implementa recursos compartilhados centralmente, como modelos de serviço, e os fornece a diferentes linhas de negócios. A "gestão de clientes" pode ser um exemplo deste tipo de capacidade. No nosso exemplo Tailwind Traders, tanto as linhas de negócio asiáticas como europeias usam a mesma administração para os seus clientes.

Mas como você pode projetar a propriedade de dados de domínio em um recurso compartilhado? Vários representantes de negócios provavelmente assumem a responsabilidade pelos clientes que estão dentro da mesma administração compartilhada.

Há um domínio de aplicativo e um domínio de dados. Seu domínio e contexto delimitado não se alinham perfeitamente do ponto de vista do produto de dados. Você pode, por outro lado, argumentar que ainda há uma única preocupação com dados do ponto de vista da capacidade de negócios.

Para recursos compartilhados, como pacotes complexos de fornecedores, soluções SaaS e sistemas legados, seja consistente em sua abordagem de propriedade de dados de domínio. Você pode segregar a propriedade dos dados por meio de produtos de dados, o que pode exigir melhorias no aplicativo. No nosso exemplo de "gestão de clientes" da Tailwind Traders, diferentes pipelines do domínio da aplicação podem gerar vários produtos de dados: um produto de dados para todos os clientes relacionados com a Ásia e outro para todos os clientes relacionados com a Europa. Nessa situação, vários domínios de dados se originam do mesmo domínio de aplicativo.

Você também pode pedir aos domínios do aplicativo para criar um único produto de dados que encapsula metadados para distinguir a propriedade dos dados dentro de si mesmo. Você pode, por exemplo, reservar um nome de coluna para propriedade, mapeando cada linha para um único domínio de dados específico.

Identifique monólitos que oferecem vários recursos de negócios

Preste atenção também aos aplicativos que atendem a vários recursos de negócios, que são frequentemente vistos em grandes empresas tradicionais. Em nosso cenário de exemplo, a Tailwind Traders usa um pacote de software complexo para facilitar tanto a "gestão de custos" quanto "ativos e financiamento". Esses aplicativos compartilhados são monólitos que fornecem o maior número possível de recursos, tornando-os grandes e complexos. Em tal situação, o domínio do aplicativo deve ser maior. A mesma coisa se aplica à propriedade compartilhada, na qual vários domínios de dados residem em um domínio de aplicativo.

Padrões de design para domínios alinhados à origem, reentrega e alinhados ao consumidor

Ao mapear seus domínios, você pode escolher um padrão com base na criação, consumo ou reentrega de seus dados. Para sua arquitetura, você pode criar modelos que suportem seus domínios com base nas características específicas do domínio.

Domínios alinhados ao sistema de origem

Os domínios alinhados ao sistema de origem estão alinhados com os sistemas de origem onde os dados se originam. Estes sistemas são tipicamente transacionais ou operacionais.

Seu objetivo é capturar dados diretamente desses sistemas de fonte dourada. Leitura e otimização de produtos de dados de seus domínios de fornecimento para consumo intensivo de dados. Facilite esses domínios usando serviços padronizados para transformação e compartilhamento de dados.

Esses serviços, que incluem estruturas de contêiner pré-configuradas, permitem que suas equipes de domínio orientadas à origem publiquem dados com mais facilidade. É o caminho de menor resistência com o mínimo de interrupção e custo.

Domínios alinhados com o consumidor

Os domínios alinhados ao consumidor são o oposto dos domínios alinhados à fonte. Eles estão alinhados com casos de uso específicos do usuário final que exigem dados de outros domínios. Os domínios alinhados ao cliente consomem e transformam dados para se adequarem aos casos de uso da sua organização.

Considere oferecer serviços de dados compartilhados para transformação e consumo de dados para atender a essas necessidades de consumo. Você pode oferecer recursos de infraestrutura de dados independentes de domínio, por exemplo, para lidar com pipelines de dados, infraestrutura de armazenamento, serviços de streaming, processamento analítico e assim por diante.

Domínios de reentrega

A reutilização de dados é um cenário diferente e mais difícil. Por exemplo, se os consumidores a jusante estiverem interessados numa combinação de dados de domínios diferentes, pode criar produtos de dados que agreguem dados ou combinem dados de alto nível exigidos por muitos domínios. Isso permite que você evite o trabalho repetitivo.

Não crie dependências fortes entre seus produtos de dados e casos de uso analíticos. Em vez disso, procure flexibilidade e acoplamento solto. O modelo a seguir demonstra como você pode alcançar flexibilidade. Um domínio assume a propriedade de produtos de dados e casos de uso analíticos e projetou processos separados para criação de produtos de dados e uso de dados.

Definir padrões de domínio sobrepostos

A modelagem de domínio geralmente fica complicada quando dados ou lógica de negócios são compartilhados entre domínios. Em organizações de grande escala, os domínios geralmente dependem de dados de outros domínios. Pode ser útil ter domínios genéricos que forneçam lógica de integração de uma forma que permita que outros subdomínios padronizem e se beneficiem dela. Mantenha seu modelo compartilhado entre subdomínios pequeno e sempre alinhado com a linguagem onipresente.

Para requisitos de dados sobrepostos, você pode usar padrões diferentes do design controlado por domínio. Aqui está um breve resumo dos padrões que você pode escolher:

• Um padrão de maneiras separado pode ser usado se você preferir o custo associado da duplicação à reutilização. A reutilização é sacrificada para maior flexibilidade e agilidade.
• Um padrão cliente-fornecedor pode ser usado se um domínio for forte e estiver disposto a se apropriar dos dados e necessidades dos consumidores a jusante. As desvantagens incluem preocupações conflitantes e forçar suas equipes de downstream a negociar entregas e prioridades de cronograma.
• Um padrão de parceria pode ser usado quando sua lógica de integração é coordenada de maneira não planejada dentro de um domínio recém-criado. Todas as equipas cooperam e têm em conta as necessidades umas das outras. Uma vez que ninguém pode mudar livremente a lógica partilhada, é necessário um compromisso significativo por parte de todos os envolvidos.
• Um padrão conformista pode ser usado para conformar todos os seus domínios a todos os requisitos. Use esse padrão quando seu trabalho de integração for complexo, nenhuma outra parte puder ter controle ou você usar pacotes de fornecedores.

Em todos os casos, seus domínios devem aderir aos seus padrões de interoperabilidade. Um domínio de parceria que produz novos dados para outros domínios deve expor seus produtos de dados como qualquer outro domínio, incluindo assumir a propriedade.

Responsabilidades de domínio

A malha de dados descentraliza a propriedade dos dados, distribuindo-os entre as equipes de domínio. Para muitas organizações, isso significa uma mudança de um modelo centralizado em torno da governança para um modelo federado. Às equipas de domínio são atribuídas tarefas, tais como:

• Apropriar-se de pipelines de dados, como ingestão, limpeza e transformação de dados, para atender ao maior número possível de necessidades de dados do cliente
• Melhorar a qualidade dos dados, incluindo a adesão aos SLAs e medidas de qualidade definidas pelos consumidores de dados
• Encapsulando metadados ou usando nomes de colunas reservadas para filtragem refinada em nível de linha e coluna
• Adesão aos padrões de gerenciamento de metadados, incluindo:
  • Registro de esquema do aplicativo e do sistema de origem
  • Metadados para melhorar a capacidade de descoberta
  • Informações sobre controle de versão
  • Ligação de atributos de dados e termos comerciais
  • Integridade das informações de metadados para permitir uma melhor integração entre domínios
• Adesão às normas de interoperabilidade de dados, incluindo protocolos, formatos de dados e tipos de dados
• Fornecimento de linhagem ligando sistemas de origem e serviços de integração a scanners ou fornecendo manualmente linhagem
• Adesão a tarefas de compartilhamento de dados, incluindo revisões de acesso ao IAM e criação de contratos de dados

Nível de granularidade para dissociação

Agora que você sabe como reconhecer e facilitar domínios de dados, pode aprender a projetar o nível certo de granularidade de domínio e regras para dissociação. Duas dimensões importantes estão em jogo quando você decompõe sua arquitetura.

A granularidade para domínios funcionais e a definição de contextos limitados é uma dimensão. Os domínios estão em conformidade com uma maneira específica de trabalhar, garantindo que os dados fiquem disponíveis para todos os domínios usando serviços compartilhados, assumindo a propriedade, aderindo aos padrões de metadados e assim por diante.

Defina limites refinados sempre que possível para a distribuição de dados. Tornar-se orientado por dados é tornar os dados disponíveis para reutilização intensiva. Se você tornar seus limites muito frouxos, forçará acoplamentos indesejados entre muitos aplicativos e perderá a reutilização de dados. Esforce-se para dissociar cada vez que os dados cruzam os limites dos recursos de negócios. Dentro de um domínio, o acoplamento apertado dentro da arquitetura interna do domínio é permitido. No entanto, ao cruzar os limites dos recursos de negócios, os domínios devem permanecer dissociados e distribuir produtos de dados otimizados para leitura para compartilhamento com outros domínios.

A granularidade para domínios técnicos e utilização de infraestrutura é a outra dimensão importante. Suas zonas de aterrissagem de dados permitem agilidade na manutenção de aplicativos de dados, que criam produtos de dados. Como criar esse tipo de zona de pouso com infraestrutura e serviços compartilhados por baixo? Os domínios funcionais são agrupados logicamente e são bons candidatos para compartilhar a infraestrutura da plataforma. Aqui estão alguns fatores a considerar ao criar essas zonas de pouso:

• A coesão e a eficiência ao trabalhar e compartilhar dados são um forte impulsionador do alinhamento de domínios funcionais a uma zona de aterrissagem de dados. Isso está relacionado à gravidade dos dados, a tendência de compartilhar constantemente grandes produtos de dados entre domínios.
• Os limites regionais podem resultar na implementação de zonas de aterragem de dados adicionais.
• Propriedade, segurança ou limites legais podem forçar a segregação de domínios. Por exemplo, alguns dados não podem ser visíveis para outros domínios.
• A flexibilidade e o ritmo da mudança são motores importantes. Alguns domínios podem ter uma alta velocidade de inovação, enquanto outros domínios valorizam fortemente a estabilidade.
• Os limites funcionais podem afastar as equipas. Um exemplo disso poderiam ser as fronteiras orientadas para a fonte e para o consumidor. Metade das suas equipas de domínio pode valorizar determinados serviços em detrimento de outros.
• Se você quiser potencialmente vender ou separar sua capacidade, você deve evitar a integração total com serviços compartilhados de outros domínios.
• O tamanho da equipe, as habilidades e a maturidade podem ser fatores importantes. Equipes altamente qualificadas e maduras geralmente preferem operar seus próprios serviços e infraestrutura, enquanto equipes menos maduras são menos propensas a valorizar a sobrecarga extra de manutenção da plataforma.

Antes de provisionar muitas zonas de aterrissagem de dados, examine a decomposição do domínio e determine quais domínios funcionais são candidatos para compartilhar a infraestrutura subjacente.

Resumo

A modelagem de recursos de negócios ajuda você a reconhecer e organizar melhor seus domínios em uma arquitetura de malha de dados. Ele fornece uma visão holística da maneira como os dados e aplicativos agregam valor ao seu negócio, ao mesmo tempo em que ajuda você a priorizar e se concentrar em sua estratégia de dados e necessidades de negócios. Você também pode usar a modelagem de recursos de negócios para mais do que apenas dados. Por exemplo, se a escalabilidade for uma preocupação, você pode usar esse modelo para identificar seus recursos principais mais críticos e desenvolver uma estratégia para eles.

Alguns profissionais levantam a preocupação de que construir uma arquitetura de estado-alvo mapeando tudo antecipadamente seja um exercício intensivo. Em vez disso, eles sugerem que você identifique seus domínios organicamente enquanto os integra à sua nova arquitetura de malha de dados. Em vez de definir seu estado de destino de cima para baixo, você trabalha de baixo para cima, explorando, experimentando e fazendo a transição de seu estado atual para um estado de destino. Embora esta abordagem proposta possa ser mais rápida, comporta riscos significativos. Você pode facilmente estar no meio de uma operação complexa de mudança ou remodelação quando as coisas começam a quebrar. Trabalhar a partir de ambas as direções, de cima para baixo e de baixo para cima, e depois reunir-se no meio ao longo do tempo é uma abordagem mais matizada.

Próximo passo

• O que é um produto de dados?