Dominios de datos

La malla de datos, en esencia, se basa en la descentralización y la distribución de responsabilidad a los dominios. Si realmente entiende esta parte de la empresa, está en mejor disposición 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 realizar una descomposición de la arquitectura de datos. El fundador de la malla de datos Zhamak Dehghani promueve el enfoque de diseño de Domain-Driven (DDD) para el desarrollo de software como un método útil para ayudarle a identificar los dominios de datos.

La dificultad para 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 datos empresariales y, para los profesionales de administración de datos, su método puede ser abstracto y técnico. A menudo también hay una falta de comprensión de DDD. Los profesionales encuentran sus nociones conceptuales demasiado difíciles de entender o intentan proyectar ejemplos de arquitectura de software o programación orientada a objetos en su panorama de datos. En este artículo se proporcionan instrucciones pragmáticas y vocabulario claro para que pueda comprender y usar DDD.

Diseño basado en dominios

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

DDD diferencia entre contextos limitados, dominios y subdominios. Los dominios son espacios problemáticos que desea solucionar. Son áreas en las que se unen el conocimiento, 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 idioma 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 descomponer un dominio en subdominios que corresponden cada uno a un problema empresarial específico como se indica en Operacionalización de la malla de datos para inteligencia artificial y aprendizaje automático.

No todos los subdominios son los mismos. Por ejemplo, puede clasificar dominios para que sean principales, genéricos o auxiliares. 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 no son específicos y, por lo general, son fáciles de resolver con productos de uso corriente. La compatibilidad con subdominios no ofrece ventaja competitiva, pero son necesarias para mantener una organización en ejecución y, por lo general, no son complejas.

Los contextos enlazados 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 en la que 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 enlazados, puede haber alineación, no hay ninguna regla dura que enlace las dos juntas. Los contextos limitados 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? ¿Qué podría tener una transición del modelado de datos empresariales al modelado de diseño controlado por dominio? ¿Qué lecciones puede tomar de DDD para la administración de datos?

Descomposición empresarial funcional de los espacios de problemas

Antes de permitir que sus equipos operen sus datos de un extremo a otro, examine el ámbito y comprenda los espacios de problemas que intenta solucionar. Es importante realizar este ejercicio primero 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 su arquitectura empresarial al agrupar los espacios de problemas. Dentro de la arquitectura empresarial, existen capacidades empresariales: habilidades o capacidades que un negocio posee o intercambia para lograr un propósito o 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 siguiente modelo.

Tailwind Traders debe dominar todas las áreas funcionales enumeradas en el mapa de funcionalidad empresarial para que se realice correctamente. Tailwind Traders debe poder vender billetes como parte de los sistemas de administración de vales en línea o sin conexión, por ejemplo, o tener pilotos disponibles para volar aviones como parte de un programa de administración piloto. La empresa puede subcontratar algunas actividades mientras mantiene a otros como el núcleo de su negocio.

Lo que observará 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 la misma funcionalidad empresarial comparten el mismo vocabulario. Lo mismo ocurre con sus aplicaciones y procesos, que normalmente están bien alineados y estrechamente conectados en función de la cohesión de las actividades que respaldan.

La asignación de funcionalidades empresariales es un excelente punto de partida, pero su historia no termina aquí.

Asignación de funcionalidades 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 tienen como destino los espacios de problemas. 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 desacopladas de las aplicaciones que están alineadas con otras funcionalidades empresariales, ya que 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 esperar una alineación completa entre dominios y los contextos delimitados correspondientes, pero, como aprenderá en 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 ser similares 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 la administración de clientes 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 en otros dominios. En este enfoque, todos los productos de datos también se alinean con el dominio y heredan el lenguaje omnipresente, que es un lenguaje construido y 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 funcionalidad empresarial que se pueden crear instancias de algunas funcionalidades empresariales varias veces.

Por ejemplo, Tailwind Traders podría tener varias realizaciones localizadas (o implementaciones) de «manipulación de equipaje y artículos perdidos». Supongamos que una línea de su negocio solo opera en Asia. En este contexto, «manipulación de equipaje y artículos perdidos» es una funcionalidad que se cumple con los aviones relacionados con 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 de las instancias de funcionalidad y funcionalidad empresarial (realizaciones) es de uno a varios. Por este motivo, terminará con (sub)dominios adicionales.

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 que se encuentran dentro de la misma administración compartida.

Hay un dominio de aplicación y un dominio de datos. El dominio y el contexto enlazado no se alinean perfectamente desde un punto de vista del producto de datos. Por el contrario, podría discutir que todavía hay una única preocupación de datos desde un punto de vista de la funcionalidad empresarial.

En el caso de funcionalidades compartidas como paquetes complejos de proveedores, soluciones SaaS y sistemas heredados, sea coherente en el 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 pueden 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, se originan varios dominios de datos 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 empresas grandes y tradicionales. En nuestro escenario de ejemplo, Tailwind Traders usa un paquete de software complejo para facilitar la «administración de costes» 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 de reenvío, alineados con el origen y alineados con el consumidor

Al asignar los dominios, puede elegir un patrón basado en la creación, el consumo o el reenvío de los datos. Para la arquitectura, puede diseñar plantillas que admitan los 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.

El objetivo es capturar datos directamente desde estos sistemas de origen privilegiado. Lea los productos de datos optimizados desde los dominios que proporcionan para el 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 a origen publiquen datos con mayor facilidad. Es el camino de la menor resistencia con una interrupción y un coste mínimos.

Dominios alineados con el consumidor

Los dominios alineados con 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 los 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 redelivery

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 distintos dominios, 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. En cambio, busque la flexibilidad y el acoplamiento flexible. En el siguiente modelo se muestra cómo se puede lograr flexibilidad. Un dominio toma posesión de los productos de datos y los casos de uso analítico, 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 suele resultar complicado 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 subdominios pequeños y siempre alineados con el lenguaje omnipresente.

Para los requisitos de datos superpuestos, puede usar diferentes patrones 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 formas independientes si prefiere el coste asociado de duplicación sobre la reutilización. La reutilización se sacrifica por mayor flexibilidad y agilidad.
• Se puede usar un patrón de proveedor de clientes si un dominio es seguro y está dispuesto a tomar posesión de los datos y necesidades de los consumidores de bajada. Los inconvenientes son el conflicto de intereses y el hecho de obligar a los equipos posteriores a negociar los resultados y las prioridades del calendario.
• 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 cooperan y tienen en cuenta 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 usar un patrón conforme para cumplir todos los dominios con todos los requisitos. Utilice este patrón cuando el trabajo de integración sea complejo, cuando ninguna otra parte pueda tener control o cuando utilice 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.

Alineación de responsabilidades

La malla de datos descentraliza la propiedad de los datos mediante su distribución 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. Los equipos de dominio se asignan tareas, como:

• Tomar posesión de las canalizaciones de datos, como la ingesta, la limpieza y la transformación de datos, para atender tantas necesidades del cliente 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
• Encapsulación de metadatos o uso de nombres de columna reservados para el filtrado de filas y de nivel de columna específicos
• Cumplimiento de los estándares de administración de metadatos, entre los que se incluyen:
  • Registro de esquemas del sistema de origen y aplicación
  • 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
• Adhesión a 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 el linaje manualmente
• Adhesión a las tareas de uso compartido de datos, incluidas las revisiones de acceso de IAM y la creación de contratos de datos

Nivel de granularidad para desacoplamiento

Ahora sabe cómo reconocer y facilitar dominios de datos, puede aprender a diseñar el nivel correcto de granularidad y reglas de dominio para la desacoplamiento. Cuando se descompone la arquitectura, están en juego dos dimensiones importantes.

La granularidad de los dominios funcionales y el establecimiento de contextos limitados es 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 su reutilización intensiva. Si hace que los límites sean demasiado sueltos, forzará los acoplamientos no deseados entre muchas aplicaciones y perderá la reutilización de datos. Se esfuerza por desacoplar cada vez que los datos cruzan los límites de las funcionalidades 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 de las aplicaciones de datos de mantenimiento, que crean productos de datos. ¿Cómo se crea este tipo de zona de aterrizaje con infraestructuras y servicios compartidos por 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 grandes productos de datos 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 obligarle a separar 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ían ser límites orientados a orígenes y orientados al consumidor. La mitad de los equipos de dominio podrían valorar determinados servicios sobre otros.
• Si desea vender o separar potencialmente la funcionalidad, debe evitar la integración estrechamente con los servicios compartidos de otros dominios.
• El tamaño del equipo, las aptitudes y la madurez pueden ser factores importantes. A menudo, los equipos altamente cualificados y maduros prefieren operar sus propios servicios e infraestructuras, mientras que los equipos menos maduros tienen menos probabilidades de 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 funcionalidades empresariales le ayuda a reconocer y organizar mejor los dominios en una arquitectura de malla de datos. Proporciona una visión holística de la forma en que los datos y las aplicaciones ofrecen valor a su negocio, 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 algo 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 ellas.

Algunos profesionales plantean la preocupación de que la construcción de una arquitectura de estado objetivo mediante el mapeo de todo por adelantado es un ejercicio intensivo. En su lugar, sugieren identificar los dominios de forma orgánica mientras los incorpora a la nueva arquitectura de malla de datos. En lugar de definir el estado de destino de arriba abajo, trabaja de abajo arriba, explorando, experimentando y realizando la transición del estado actual hacia un estado de destino. Aunque este enfoque propuesto podría ser más rápido, conlleva un riesgo significativo. Puede estar fácilmente en medio de una operación compleja de movimiento o remodelación cuando las cosas empiezan a romperse. Trabajar desde ambas direcciones, de arriba abajo y de abajo 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?