Dominios de datos

La malla de datos se basa fundamentalmente en la descentralización y la distribución de responsabilidad a los dominios. Si realmente comprende una parte de la empresa, está mejor posicionada para administrar los datos asociados y garantizar su precisión. Este es el principio de propiedad de datos orientada a dominio.

Para promover la propiedad de datos orientada a dominio, primero debe descomponer la arquitectura de datos. El fundador del concepto de malla de datos, Zhamak Dehghani, promueve el enfoque de Diseño Dirigido por el Dominio (DDD) para el desarrollo de software como un método útil para ayudar a identificar tus dominios de datos.

La dificultad de usar DDD para la administración de datos es que el caso de uso original de DDD estaba modelando sistemas complejos en un contexto de desarrollo de software. Originalmente no se creó para modelar los datos empresariales y para los profesionales de la administración de datos, su método puede ser abstracto y técnico. A menudo hay una falta de comprensión del Diseño Dirigido por Dominios (DDD). Los profesionales encuentran sus nociones conceptuales demasiado difíciles de entender o tratar de proyectar ejemplos de arquitectura de software o programación orientada a objetos en su paisaje de datos. En este artículo se proporcionan instrucciones pragmáticas y vocabulario claro para que pueda comprender y usar DDD.

Diseño controlado por dominio

Presentado por Eric Evans, Domain-Driven Design es un método para apoyar el desarrollo de software que ayuda a describir sistemas complejos para grandes organizaciones. DDD es popular porque muchas de sus prácticas de alto nivel afectan a los enfoques modernos de desarrollo de aplicaciones y software, como los microservicios.

DDD diferencia entre contextos enlazados, dominios y subdominios. Los dominios son espacios problemáticos que desea solucionar. Son áreas en las que se reúnen los conocimientos, el comportamiento, las leyes y las actividades. Verá el acoplamiento semántico en dominios, dependencias de comportamiento entre componentes o servicios. Otro aspecto de los dominios es la comunicación. Los miembros del equipo deben usar un idioma que todo el equipo comparte para que todos puedan trabajar de forma eficaz. Este lenguaje compartido se denomina lenguaje ubicuo o idioma de dominio.

Los dominios se descomponen en subdominios para administrar mejor la complejidad. Un ejemplo común de esto es descomponir un dominio en subdominios que cada uno corresponde a un problema empresarial específico, como se muestra en Operationalize data mesh for AI/ML.

No todos los subdominios son los mismos. Por ejemplo, puede clasificar dominios como núcleos, genéricos o compatibles. Los subdominios principales son los más importantes. Son la salsa secreta, los ingredientes, que hacen que una organización sea única. Los subdominios genéricos son no específicos y, por lo general, son fáciles de resolver con productos fuera de la estantería. Los subdominios de soporte no ofrecen una ventaja competitiva, pero son necesarios para mantener una organización funcionando y no son complejos.

Contextos delimitados son límites lógicos (contexto). Se centran en el espacio de la solución: el diseño de sistemas y aplicaciones. Es un área donde tiene sentido la alineación del foco en el espacio de la solución. En DDD, esto puede incluir código, diseños de base de datos, etc. Entre los dominios y los contextos delimitados, puede haber alineación, pero no hay ninguna regla estricta que enlace los dos juntos. Los contextos delimitados son técnicos por naturaleza y pueden abarcar varios dominios y subdominios.

Recomendaciones de modelado de dominio

Si adopta la malla de datos como concepto para la democratización de los datos e implementa el principio de propiedad de datos orientada a dominio para aumentar la flexibilidad, ¿cómo funciona en la práctica? ¿Cómo podría ser una transición del modelado de datos empresariales al modelado de diseño dirigido por el dominio? ¿Qué lecciones puede tomar de DDD para la administración de datos?

Hacer una descomposición empresarial funcional de los espacios de problemas

Antes de permitir que los equipos gestionen sus datos de un extremo a otro, examine el alcance del proyecto y comprenda las áreas problemáticas que intenta solucionar. Es importante hacer este ejercicio en primer lugar antes de pasar a los detalles de una implementación técnica. Al establecer límites lógicos entre estos espacios de problemas, las responsabilidades se vuelven más claras y se pueden administrar mejor.

Examine la arquitectura empresarial al agrupar los espacios de problemas. Dentro de la arquitectura empresarial, hay capacidades empresariales: habilidades o capacidades que una empresa posee o que intercambian para lograr un propósito o alcanzar un resultado específico. Esta abstracción empaqueta los datos, los procesos, la organización y la tecnología en un contexto determinado, en consonancia con los objetivos y objetivos empresariales estratégicos de su organización. Un mapa de funcionalidad empresarial muestra qué áreas funcionales parecen ser necesarias para cumplir su misión y visión.

Puede ver la descomposición de la funcionalidad de una empresa ficticia, Tailwind Traders, en el modelo siguiente.

Tailwind Traders debe dominar todas las áreas funcionales enumeradas en el mapa de capacidades empresariales para tener éxito. Tailwind Traders debe poder vender boletos como parte de sistemas de gestión de boletos online o offline, por ejemplo, o tener pilotos disponibles para volar aviones como parte de un programa de gestión de pilotos. La empresa puede subcontratar algunas actividades mientras mantiene a otros como el núcleo de su negocio.

Lo que observa en la práctica es que la mayoría de sus personas están organizadas en torno a las capacidades empresariales. Las personas que trabajan en las mismas funcionalidades empresariales comparten el mismo vocabulario. Lo mismo sucede con las aplicaciones y los procesos, que normalmente están bien alineados y estrechamente conectados en función de la cohesión de las actividades que respaldan.

El mapeo de capacidades empresariales es un excelente punto de partida, pero tu historia no termina aquí.

Mapear las capacidades empresariales a aplicaciones y datos

Para administrar mejor la arquitectura empresarial, alinee las funcionalidades empresariales, los contextos limitados y las aplicaciones. Es importante seguir algunas reglas básicas al hacerlo.

Las funcionalidades empresariales deben permanecer en el nivel empresarial y permanecer abstractas. Representan lo que hace su organización y se centran en las áreas problemáticas. Al implementar una funcionalidad empresarial, se crea una realización (instancia de funcionalidad) para un contexto específico. Varias aplicaciones y componentes funcionan conjuntamente dentro de estos límites en el espacio de la solución para ofrecer un valor empresarial específico.

Las aplicaciones y los componentes alineados con una funcionalidad empresarial determinada permanecen desacoplados de las aplicaciones que están alineadas con otras funcionalidades empresariales porque abordan diferentes preocupaciones empresariales. Los contextos limitados se derivan de y se asignan exclusivamente a las funcionalidades empresariales. Representan el límite de una implementación de funcionalidad empresarial y se comportan como un dominio.

Si cambian las funcionalidades empresariales, cambian los contextos limitados. Es preferible que se espere una alineación completa entre los dominios y los contextos delimitados correspondientes, pero como aprenderás en las secciones posteriores, la realidad a veces difiere del ideal.

Si proyectamos la asignación de funcionalidades a Tailwind Traders, los límites de contexto limitado y las implementaciones de dominio podrían tener un aspecto similar al diagrama siguiente.

En este diagrama, la administración de clientes se basa en la experiencia en la materia y, por tanto, sabe mejor qué datos servir a otros dominios. La arquitectura interna de Customer Management está desacoplada, por lo que todos los componentes de la aplicación dentro de estos límites pueden comunicarse directamente mediante interfaces y modelos de datos específicos de la aplicación.

Los productos de datos y los estándares de interoperabilidad claros se usan para formalizar la distribución de datos a otros dominios. En este enfoque, todos los productos de datos también se alinean con el dominio y heredan el lenguaje ubicuo, que es un lenguaje construido, formalizado acordado por las partes interesadas y diseñadores del mismo dominio, para satisfacer las necesidades de ese dominio.

Dominios adicionales de varias realizaciones de funcionalidades

Es importante reconocer, al trabajar con mapas de capacidades empresariales, que algunas capacidades empresariales pueden instanciarse varias veces.

Por ejemplo, Tailwind Traders podría tener varias implementaciones localizadas (o implementaciones) de "manipulación de equipaje y artículos perdidos". Supongamos que una línea de su negocio opera solo en Asia. En este contexto, "manejo de equipaje y artículos perdidos" es una función que se cumple para aviones con rutas hacia Asia. Una línea de negocio diferente podría dirigirse al mercado europeo y, en este contexto, se utiliza otra funcionalidad de "manipulación de equipajes y artículos perdidos". Este escenario de varias instancias puede dar lugar a varias implementaciones localizadas mediante diferentes servicios tecnológicos y equipos separados para operar esos servicios.

La relación entre la capacidad empresarial y las instancias de capacidad (realizaciones) es de uno a varios. Por este motivo, terminará con dominios adicionales (sub-).

Búsqueda de funcionalidades compartidas y cuidado con los datos compartidos

Es importante controlar las funcionalidades empresariales compartidas. Normalmente, se implementan funcionalidades compartidas de forma centralizada, como modelos de servicio, y se proporcionan a diferentes líneas de negocio. "Administración de clientes" puede ser un ejemplo de este tipo de funcionalidad. En nuestro ejemplo de Tailwind Traders, las líneas de negocio asiáticas y europeas usan la misma administración para sus clientes.

¿Pero cómo puede proyectar la propiedad de los datos de dominio en una funcionalidad compartida? Es probable que varios representantes empresariales asuman la responsabilidad de los clientes dentro de la misma administración compartida.

Hay un dominio de aplicación y un dominio de datos. El dominio y el contexto delimitado no se alinean perfectamente desde la perspectiva de un producto de datos. Por otro lado, podría argumentar que todavía hay una única cuestión de datos desde el punto de vista de la capacidad empresarial.

Para capacidades compartidas, como paquetes complejos de proveedores, soluciones SaaS y sistemas heredados, sea coherente en su enfoque de propiedad de los datos del dominio. Puede separar la propiedad de los datos a través de productos de datos, lo que podría requerir mejoras en la aplicación. En nuestro ejemplo de "Administración de clientes" de Tailwind Traders, diferentes canalizaciones del dominio de aplicación podrían generar varios productos de datos: un producto de datos para todos los clientes relacionados con Asia y otro para todos los clientes relacionados con Europa. En esta situación, varios dominios de datos se originan en el mismo dominio de aplicación.

También puede pedir a los dominios de aplicación que creen un único producto de datos que encapsula los metadatos para distinguir la propiedad de los datos dentro de sí mismo. Por ejemplo, podría reservar un nombre de columna para la propiedad, asignando cada fila a un único dominio de datos específico.

Identificación de monolitos que ofrecen varias funcionalidades empresariales

Preste atención también a las aplicaciones que satisfacen varias funcionalidades empresariales, que a menudo se ven en grandes y tradicionales empresas. En nuestro escenario de ejemplo, Tailwind Traders usa un paquete de software complejo para facilitar la "administración de costos" y "activos y financiación". Estas aplicaciones compartidas son monolíticas que proporcionan tantas características como sea posible, lo que las convierte en grandes y complejas. En tal situación, el dominio de aplicación debe ser mayor. Lo mismo se aplica a la propiedad compartida, en la que varios dominios de datos residen en un dominio de aplicación.

Patrones de diseño para dominios alineados con el origen, alineados con la reentrega y alineados con el consumidor

Al mapear sus dominios, puede elegir un patrón basado en la creación, el consumo o la reentrega de sus datos. Para su arquitectura, puede diseñar plantillas que admitan sus dominios en función de las características específicas del dominio.

Dominios alineados con el sistema de origen

Los dominios alineados con el sistema de origen se alinean con los sistemas de origen donde se originan los datos. Estos sistemas suelen ser transaccionales o operativos.

Su objetivo es capturar datos directamente desde estos sistemas fuente únicos. Productos de datos optimizados para lectura desde tus dominios proveedores para un consumo intensivo de datos. Facilitar estos dominios mediante servicios estandarizados para la transformación y el uso compartido de datos.

Estos servicios, que incluyen estructuras de contenedor preconfiguradas, permiten que los equipos de dominio orientados al origen publiquen datos con mayor facilidad. Es el camino de la menor resistencia con una interrupción y un costo mínimos.

Dominios alineados con el consumidor

Los dominios alineados por el consumidor son los opuestos a los dominios alineados con el origen. Están alineados con casos de uso específicos del usuario final que requieren datos de otros dominios. Los dominios alineados con el cliente consumen y transforman datos para ajustarse a los casos de uso de su organización.

Considere la posibilidad de ofrecer servicios de datos compartidos para la transformación y el consumo de datos para satisfacer estas necesidades de consumo. Puede ofrecer funcionalidades de infraestructura de datos independientes del dominio, por ejemplo, para controlar canalizaciones de datos, infraestructura de almacenamiento, servicios de streaming, procesamiento analítico, etc.

Dominios de reenvío

La reutilización de los datos es un escenario diferente y más difícil. Por ejemplo, si los consumidores de nivel inferior están interesados en una combinación de datos de dominios diferentes, puede crear productos de datos que agreguen datos o combinen datos de alto nivel requeridos por muchos dominios. Esto le permite evitar el trabajo repetitivo.

No cree dependencias sólidas entre los productos de datos y los casos de uso analíticos. Más bien, esfuércese por la flexibilidad y el acoplamiento débil. En el siguiente modelo se muestra cómo puede lograr flexibilidad. Un dominio toma posesión de los productos de datos y los casos de uso analíticos y ha diseñado procesos independientes para la creación de productos de datos y el uso de datos.

Definición de patrones de dominio superpuestos

El modelado de dominios a menudo se complica cuando los datos o la lógica de negocios se comparten entre dominios. En organizaciones a gran escala, los dominios suelen depender de datos de otros dominios. Puede resultar útil tener dominios genéricos que proporcionen lógica de integración de una manera que permita que otros subdominios normalicen y se beneficien de él. Mantenga el modelo compartido entre pequeños subdominios siempre alineado con el lenguaje omnipresente.

Para los requisitos de datos superpuestos, puede usar patrones diferentes del diseño controlado por dominio. Este es un breve resumen de los patrones entre los que puede elegir:

• Se puede usar un patrón de caminos separados si prefiere el costo asociado de duplicación sobre la reutilización. La reutilización se sacrifica por mayor flexibilidad y agilidad.
• Se puede utilizar un patrón de cliente-proveedor si un dominio es fuerte y está dispuesto a asumir la responsabilidad de los datos y necesidades de los consumidores posteriores. Entre los inconvenientes se incluyen problemas en conflicto y se fuerza a los equipos de nivel inferior a negociar resultados y programar prioridades.
• Se puede usar un patrón de asociación cuando la lógica de integración se coordina de forma no planeada dentro de un dominio recién creado. Todos los equipos colaboran y consideran las necesidades de los demás. Dado que nadie puede cambiar libremente la lógica compartida, se necesita un compromiso significativo de todos los implicados.
• Se puede utilizar un patrón de conformidad para ajustar todos los dominios a todos los requisitos. Use este patrón cuando el trabajo de integración sea complejo, ninguna otra parte pueda tener control o use paquetes de proveedor.

En todos los casos, los dominios deben cumplir los estándares de interoperabilidad. Un dominio de asociación que genere nuevos datos para otros dominios debe exponer sus productos de datos como cualquier otro dominio, incluida la toma de posesión.

Responsabilidades de dominio

La malla de datos descentraliza la propiedad de los datos distribuyéndola entre los equipos de dominio. Para muchas organizaciones, esto significa un cambio de un modelo centralizado en torno a la gobernanza a un modelo federado. A los equipos de dominio se les asignan tareas, como:

• Tomar posesión de las canalizaciones de datos, como la ingesta, la limpieza y la transformación de datos, para servir a tantas necesidades de los clientes de datos como sea posible
• Mejora de la calidad de los datos, incluido el cumplimiento de los Acuerdos de Nivel de Servicio y las medidas de calidad establecidas por los consumidores de datos
• Encapsular metadatos o usar nombres de columna reservados para el filtrado detallado de filas y de nivel de columna
• Cumplimiento de los estándares de administración de metadatos, entre los que se incluyen:
  • Registro de esquemas de la aplicación y del sistema fuente
  • Metadatos para mejorar la detectabilidad
  • Información de control de versiones
  • Vinculación de atributos de datos y términos empresariales
  • Integridad de la información de metadatos para permitir una mejor integración entre dominios
• Cumplimiento de los estándares de interoperabilidad de datos, incluidos protocolos, formatos de datos y tipos de datos
• Proporcionar linaje mediante la vinculación de sistemas de origen y servicios de integración a escáneres o proporcionando manualmente linaje
• Cumplimiento con las tareas que implican el intercambio de datos, incluyendo revisiones de acceso de IAM y la creación de contratos de datos

Nivel de granularidad para el desacoplamiento

Ahora que sabe cómo reconocer y facilitar dominios de datos, puede aprender a diseñar el nivel correcto de granularidad y reglas de los dominios para el desacoplamiento. Hay dos dimensiones importantes en juego cuando se descompone la arquitectura.

La granularidad de los dominios funcionales y la configuración de contextos delimitados constituye una dimensión. Los dominios se ajustan a una forma determinada de trabajar, lo que garantiza que los datos estén disponibles para todos los dominios que usan servicios compartidos, tomando posesión, cumpliendo con los estándares de metadatos, etc.

Establezca límites específicos siempre que sea posible para la distribución de datos. Convertirse en controlado por datos consiste en hacer que los datos estén disponibles para una reutilización intensiva. Si hace que los límites sean demasiado flexibles, se fuerzan acoplamientos no deseados entre muchas aplicaciones y se pierde la reutilización de datos. Esfuérzate por desacoplar cada vez que los datos cruzan los límites de las capacidades empresariales. Dentro de un dominio, se permite un acoplamiento estricto dentro de la arquitectura interna del dominio. Sin embargo, al cruzar los límites de las funcionalidades empresariales, los dominios deben permanecer desacoplados y distribuir productos de datos optimizados para lectura para compartirlos con otros dominios.

La granularidad de los dominios técnicos y el uso de la infraestructura es la otra dimensión importante. Las zonas de aterrizaje de datos permiten la agilidad en el servicio de aplicaciones de datos, que crean productos de datos. ¿Cómo se crea este tipo de zona de aterrizaje con la infraestructura y los servicios compartidos debajo? Los dominios funcionales se agrupan lógicamente y son buenos candidatos para compartir la infraestructura de la plataforma. Estos son algunos factores que se deben tener en cuenta al crear estas zonas de aterrizaje:

• La cohesión y la eficacia al trabajar con y compartir datos es un impulsor sólido de alinear dominios funcionales con una zona de aterrizaje de datos. Esto se relaciona con la gravedad de los datos, la tendencia a compartir constantemente productos de datos grandes entre dominios.
• Los límites regionales pueden dar lugar a que se implementen zonas de aterrizaje de datos adicionales.
• La propiedad, la seguridad o los límites legales pueden forzar la segregación de dominios. Por ejemplo, algunos datos no pueden ser visibles para ningún otro dominio.
• La flexibilidad y el ritmo de cambio son factores importantes. Algunos dominios pueden tener una alta velocidad de innovación, mientras que otros dominios valoran fuertemente la estabilidad.
• Los límites funcionales pueden separar los equipos. Un ejemplo de esto podría ser límites orientados al origen y orientados al consumidor. La mitad de los equipos de dominio podrían valorar determinados servicios sobre otros.
• Si desea vender o separar su funcionalidad, debe evitar una integración estrecha con los servicios compartidos de otros dominios.
• El tamaño, las aptitudes y la madurez del equipo pueden ser factores importantes. Los equipos altamente cualificados y maduros suelen preferir operar sus propios servicios e infraestructuras, mientras que los equipos menos maduros son menos propensos a valorar la sobrecarga adicional del mantenimiento de la plataforma.

Antes de aprovisionar muchas zonas de aterrizaje de datos, examine la descomposición del dominio y determine qué dominios funcionales son candidatos para compartir la infraestructura subyacente.

Resumen

El modelado de funcionalidad empresarial le ayuda a reconocer y organizar mejor los dominios en una arquitectura de malla de datos. Proporciona una vista holística de la forma en que los datos y las aplicaciones ofrecen valor a su empresa, al mismo tiempo que le ayudan a priorizar y centrarse en la estrategia de datos y las necesidades empresariales. También puede usar el modelado de funcionalidad empresarial para más que solo datos. Por ejemplo, si la escalabilidad es un problema, puede usar este modelo para identificar las funcionalidades principales más críticas y desarrollar una estrategia para ellos.

Algunos profesionales manifiestan preocupación por crear una arquitectura de estado objetivo mediante el delineamiento de todo por adelantado, ya que es un ejercicio intensivo. En cambio, ellos sugieren que identifiques los dominios de forma orgánica mientras los incorporas a tu nueva arquitectura de malla de datos. En lugar de definir tu estado objetivo desde arriba hacia abajo, trabajas desde abajo hacia arriba, exploras, experimentas y transitas desde tu estado actual hacia un estado de destino. Aunque este enfoque propuesto podría ser más rápido, conlleva un riesgo significativo. Puede encontrarse fácilmente en medio de una operación compleja de mudanza o remodelación cuando las cosas empiezan a fallar. Trabajar desde ambas direcciones, de arriba hacia abajo y de abajo hacia arriba, y luego reunirse en el medio a lo largo del tiempo es un enfoque más matizado.

Paso siguiente

• ¿Qué es un producto de datos?