Domínios de dados

A malha de dados, em essência, é fundada na descentralização e na distribuição de responsabilidade para os domínios. Se você realmente entender essa parte do negócio, estará melhor posicionado para gerenciar os dados associados e garantir sua precisão. Esse é o princípio da propriedade de dados orientada ao domínio.

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

A dificuldade de usar o DDD para gerenciamento de dados é que o caso de uso original do DDD foi modelar sistemas complexos em um contexto de desenvolvimento de software. Ele não foi criado originalmente para modelar dados corporativos e, para os profissionais de gerenciamento de dados, seu método pode ser abstrato e técnico. Também há muitas vezes uma falta de compreensão do DDD. Os profissionais acham suas noções conceituais muito difíceis de entender ou tentam projetar exemplos da arquitetura de software ou da 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 Design Determinado pelo Domínio é um método para dar suporte 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 abordagens modernas de desenvolvimento de aplicativos e software para coisas como microsserviços.

O DDD diferencia entre contextos limitados, domínios e subdomínios. Os domínios são espaços problemáticos que você deseja resolver. São áreas em que o conhecimento, os comportamentos, as leis e as atividades se reúnem. Você vê acoplamento semântico em domínios, dependências comportamentais entre componentes ou serviços. Outro aspecto dos domínios é a comunicação. Os membros da equipe devem usar uma linguagem que toda a equipe compartilha para que todos possam trabalhar com eficiência. Essa linguagem compartilhada é chamada de linguagem ubíqua ou linguagem de domínio.

Os domínios são decompostos em subdomínios para gerenciar melhor a complexidade. Um exemplo comum disso é decompor um domínio em subdomínios que correspondem 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. Por exemplo, você pode classificar os domínios como principais, genéricos ou compatíveis. Os subdomínios principais são os mais importantes. Eles são o segredo que tornam uma organização única. Subdomínios genéricos não são específicos e normalmente são fáceis de resolver com produtos fora da prateleira. Os subdomínios de suporte não oferecem vantagem competitiva, mas são necessários para manter uma organização em execução e geralmente não são complexos.

Contextos limitados são limites lógicos (contexto). Eles se concentram no espaço de solução: o design de sistemas e aplicativos. É uma área em que o alinhamento do foco no espaço da solução faz sentido. No DDD, isso pode incluir código, designs de banco de dados e assim por diante. Entre os domínios e os contextos limitados, pode haver alinhamento, não há nenhuma regra rígida associando os dois. 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 de democratização de dados e implementar o princípio da propriedade de dados orientada ao 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 design controlada pelo domínio? Quais lições você pode tirar do DDD para o gerenciamento de dados?

Fazer uma decomposição de negócios funcional dos seus espaços problemáticos

Antes de permitir que suas equipes operem seus dados de ponta a ponta, examine o escopo e entenda os espaços problemáticos que você está tentando resolver. É importante fazer esse 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 ficam mais claras e podem ser melhor gerenciadas.

Examine sua arquitetura de negócios ao agrupar seus espaços problemáticos. Dentro da arquitetura de negócios, há funcionalidades de negócios: habilidades ou capacidades que uma empresa tem ou troca para alcançar uma finalidade ou um resultado específico. Essa abstração empacota 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 funcionalidades de negócios mostra quais áreas funcionais parecem ser necessárias para cumprir sua missão e visão.

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

A Tailwind Traders precisa dominar todas as áreas funcionais listadas no Mapa de Funcionalidades de Negócios para ter êxito. A Tailwind Traders deve ser capaz de vender tíquetes como parte dos Sistemas de Gerenciamento de Tíquetes Online ou Offline, por exemplo, ou ter pilotos disponíveis para pilotar aviões como parte de um Programa de Gerenciamento de Pilotos. A empresa pode terceirizar algumas atividades mantendo outras como o núcleo de seus negócios.

O que você observará na prática é que a maioria das pessoas está organizada em torno de recursos de negócios. Pessoas trabalhando na mesma funcionalidade de negócios compartilham o mesmo vocabulário. O mesmo acontece com seus aplicativos e processos, que normalmente são bem alinhados e fortemente conectados com base na coesão das atividades a que eles dão suporte.

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

Mapear recursos de negócios para aplicativos e dados

Para gerenciar melhor sua arquitetura empresarial, alinhe seus recursos de negócios, contextos limitados e aplicativos. É importante seguir algumas regras básicas ao fazer isso.

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

Aplicativos e componentes alinhados com uma funcionalidade de negócios específica permanecem separados de aplicativos alinhados com outras funcionalidades de negócios, pois abordam diferentes preocupações comerciais. Contextos limitados são derivados e mapeados exclusivamente 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 os recursos de negócios forem alterados, os contextos limitados mudarão. Preferencialmente, esperamos alinhamento total entre domínios e contextos limitados correspondentes, mas como veremos em seções posteriores, a realidade às vezes difere um pouco do ideal.

Se projetarmos o mapeamento de capacidade para a Tailwind Traders, os limites de contexto limitados e as implementações de domínio poderão ser semelhantes ao diagrama a seguir.

Neste diagrama, o gerenciamento de clientes é criado com base na experiência do assunto e, portanto, sabe melhor quais dados servir para outros domínios. A arquitetura interna do gerenciamento de clientes é dissociada, portanto, 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. Nessa abordagem, todos os produtos de dados também se alinham com o domínio e herdam a linguagem onipresente, que é uma linguagem construída e formalizada acordada por stakeholders e designers do mesmo domínio, para atender às necessidades desse domínio.

Domínios extras de várias realizações de funcionalidade

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

Por exemplo, a Tailwind Traders pode ter várias realizações (ou implementações) localizadas de "manipulação de bagagem e itens perdidos". Suponha que uma linha dos seus negócios opere apenas na Ásia. Nesse contexto, a "manipulação de bagagem e itens perdidos" seria uma funcionalidade atendida para aviões relacionados à Ásia. Uma linha de negócios diferente pode ter como alvo o mercado europeu e, nesse contexto, outra funcionalidade de "manipulação de bagagem e itens perdidos" seria usada. Esse cenário de várias instâncias pode levar a várias implementações localizadas usando diferentes serviços de tecnologia e equipes desativadas para operar esses serviços.

A relação de instâncias de funcionalidade e capacidade de negócios (realizações) é de um para muitos. Por isso, você acaba com (sub-)domínios adicionais.

Localizar recursos compartilhados e tomar cuidado com os 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 para diferentes linhas de negócios. O "gerenciamento de clientes" pode ser um exemplo desse tipo de funcionalidade. Em nosso exemplo da Tailwind Traders, ambas as linhas de negócios, asiática e europeia, usam a mesma administração para os respectivos clientes.

Mas como você pode projetar a propriedade de dados de domínio em uma funcionalidade compartilhada? Vários representantes empresariais provavelmente levam em conta a responsabilidade para os clientes que estão na mesma administração compartilhada.

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

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

Você também pode solicitar que seus domínios de aplicativo criem apenas um produto de dados que encapsula metadados a fim de distinguir a propriedade dos dados em si mesmo. Você pode, por exemplo, reservar um nome de coluna para propriedade, mapeando cada linha para um só domínio de dados específico.

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

Preste atenção também aos aplicativos que atendem a várias funcionalidades de negócios, que geralmente são vistas em grandes e tradicionais empresas. Em nosso cenário de exemplo, a Tailwind Traders usa um pacote de software complexo para facilitar o "gerenciamento de custos" e a "gestão de 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. Nessa 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 oferecem suporte a 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 são alinhados aos sistemas de origem nos quais os dados são originados. Normalmente, esses sistemas são transacionais ou operacionais.

Seu objetivo é capturar dados diretamente desses sistemas de origem dourados. Otimize a leitura 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 interrupção e custo mínimos.

Domínios alinhados ao consumidor

Os domínios alinhados ao consumidor são o oposto dos domínios alinhados à origem. 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 ajustar aos casos de uso da sua organização.

Considere oferecer serviços de dados compartilhados para transformação e consumo de dados a fim de atender a essas necessidades de consumo. Você pode oferecer recursos de infraestrutura de dados agnósticos 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 resgate

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

Não crie dependências fortes entre seus produtos de dados e casos de uso analítico. Em vez disso, esforce-se para criar flexibilidade e acoplamento suave. O modelo a seguir demonstra como você pode obter flexibilidade. Um domínio assume a propriedade de produtos de dados e de casos de uso analíticos, e projeta processos separados para a criação de produtos de dados e o 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 fornecem lógica de integração de modo a permitir que outros subdomínios sejam padronizados e se beneficiem dele. Mantenha seu modelo compartilhado entre subdomínios pequeno e sempre alinhado com a linguagem onipresente.

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

• Um padrão de maneiras separadas pode ser usado se você preferir o custo associado da duplicação em vez da reutilização. A reutilização é sacrificada por maior flexibilidade e agilidade.
• Um padrão cliente-fornecedor pode ser usado se um domínio for forte e estiver disposto a assumir a propriedade dos dados e necessidades dos consumidores downstream. As desvantagens incluem preocupações conflitantes e forçar suas equipes downstream a negociar entregas e agendar prioridades.
• Um padrão de parceria pode ser usado quando sua lógica de integração é coordenada de maneira não planejada em um domínio recém-criado. Todas as equipes cooperam e consideram as necessidades umas das outras. Como ninguém pode alterar livremente a lógica compartilhada, é necessário um compromisso significativo de todos os envolvidos.
• Um padrão conformista pode ser usado para alinhar 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 seguir 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 de dados distribuindo-a 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 equipes de domínio são atribuídas tarefas, como:

• Assumir a propriedade de pipelines de dados – como de ingestão, limpeza e transformação de dados – para atender ao maior número possível de necessidades do cliente de dados
• Aprimoramento da qualidade dos dados, incluindo adesão a SLAs e medidas de qualidade definidas pelos consumidores de dados
• Encapsulamento de metadados ou uso de nomes de coluna reservados para uma filtragem rigorosa de linhas e colunas
• Aderência aos padrões de gerenciamento de metadados, incluindo:
  • Registro de esquema do aplicativo e sistema de origem
  • Metadados para maior capacidade de descoberta
  • Informações de controle de versão
  • Vinculação de atributos de dados e termos de negócios
  • Integridade das informações de metadados para permitir uma melhor integração entre domínios
• Adesão aos padrões de interoperabilidade de dados, incluindo protocolos, formatos de dados e tipos de dados
• Fornecimento de linhagem vinculando 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 do IAM e criação de contrato de dados

Nível de granularidade para desacoplamento

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

A granularidade para domínios funcionais e a configuração de contextos limitados é uma dimensão. Os domínios estão em conformidade com uma forma 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 distribuição de dados. Tornar-se controlado por dados se trata de disponibilizar dados para reutilização intensiva. Se você deixar seus limites muito soltos, forçará acoplamentos indesejados entre muitos aplicativos e perderá a reutilização de dados. Esforce-se para desacoplar cada vez que os dados ultrapassam os limites das funcionalidades de negócios. Dentro de um domínio, o acoplamento justo dentro da arquitetura interna do domínio é permitido. No entanto, ao cruzar os limites dos recursos de negócios, os domínios devem permanecer desacoplados e distribuir produtos de dados com otimização de leitura para compartilhar com outros domínios.

A granularidade para domínios técnicos e utilização de infraestrutura é a outra dimensão importante. Suas zonas de destino de dados permitem agilidade para a manutenção de aplicativos de dados, que criam produtos de dados. Como você cria esse tipo de zona de destino com infraestrutura e serviços compartilhados abaixo? 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 serem considerados ao criar essas zonas de destino:

• A coesão e a eficiência ao trabalhar com e compartilhar dados são um forte fator que impulsiona o alinhamento de domínios funcionais a uma zona de destino de dados. Isso se relaciona com a gravidade dos dados, a tendência de compartilhar constantemente grandes produtos de dados entre domínios.
• Limites regionais podem resultar na implementação de zonas de destino de dados extras.
• A propriedade, a segurança ou os limites legais podem forçar a segregação de domínios. Por exemplo, alguns dados não podem ser visíveis para nenhum outro domínio.
• A flexibilidade e o ritmo da mudança são fatores importantes. Alguns domínios podem ter uma alta velocidade de inovação, enquanto outros domínios valorizam fortemente a estabilidade.
• Limites funcionais podem separar as equipes. Um exemplo disso pode ser limites orientados ao consumidor e orientados à fonte. Metade das equipes de domínio pode valorizar determinados serviços em relação a outros.
• Se você quiser ter o potencial de vender ou separar sua funcionalidade, evite integrar-se muito intensamente aos serviços compartilhados de outros domínios.
• Tamanho da equipe, habilidades e 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 da manutenção da plataforma.

Antes de provisionar muitas zonas de destino de dados, examine a decomposição do domínio e determine quais domínios funcionais são candidatos a 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. Ela fornece uma visão holística da maneira como os dados e os aplicativos fornecem valor para sua empresa, 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ê poderá usar esse modelo para identificar seus recursos principais mais críticos e desenvolver uma estratégia para eles.

Alguns praticantes levantam a preocupação de que a criação da arquitetura de estado-destino mapeando tudo antecipadamente é 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 o estado de destino de cima para baixo, você trabalha de baixo para cima, explorando, experimentando e fazendo a transição do estado atual para um estado de destino. Embora essa abordagem proposta possa ser mais rápida, ela traz riscos significativos. É perfeitamente possível que ocorram interrupções quando você estiver no meio de uma operação complexa de movimentação ou remodelação. Trabalhar de ambas as direções, de cima para baixo e de baixo para cima, encontrando-se no meio ao longo do tempo, é uma abordagem mais minuciosa.

Próxima etapa

• O que é um produto de dados?