Dentro de la transformación de la arquitectura de datos de un modelo centralizado (Data Warehouse o Data Lake) a uno descentralizado (Data Mesh) podemos encontramos con un cambio de enfoque de desarrollo software, desplazándonos de un punto de vista data-driven (enfocado en los datos) a uno domain-driven (centrado en el conocimiento del dominio).
Data-Driven Design
En Data-Driven Design (DDD) se utiliza los datos para tomar decisiones y guiar el diseño y desarrollo de un sistema. Los datos se ven como el principal insumo para la construcción de ese sistema. Se utilizan para la definición de funcionalidades y características, es decir, para la toma de decisiones técnicas y arquitectónicas. El objetivo es construir sistemas que sean altamente escalables, flexibles y adaptables, y que sean capaces de responder a los cambios en los requisitos y las necesidades del negocio apoyándose en una fuerte capacidad de recopilación, almacenamiento, procesamiento y análisis de datos.
Domain-Driven Design
En Domain-driven Design (DDD) busca resolver un problema de negocio (dominio) convirtiendo el software en un reflejo del sistema en el mundo real. La toma de decisiones se basa en el conocimiento y comprensión del dominio. Éste se puede modularizar en subdominios que respondan a necesidades más específicas e independientes, mejorando la adaptabilidad, escalabilidad y resiliencia del sistema. El objetivo es crear un entorno de colaboración entre los expertos de negocio (saben el qué) y el equipo técnico (saben el cómo) para un desarrollo que sea coherente y pueda adaptarse a los cambios constantes en los requisitos.
Conceptos de Domain-Driven Design (DDD)
Los siguientes términos definen los elementos clave que componen un enfoque DDD:
- Core Domain y Subdomains se refieren al ámbito del problema o necesidad del mundo real que se busca resolver. Los dominios pueden dividirse en subdominios para centrarse en dar soluciones más acotadas modularizando el dominio en porciones más pequeñas independientes.
- Domain model representación abstracta del problema del mundo real en entidades, relaciones y reglas de negocio.
- Bounded Context sería una frontera clara y explícita alrededor de una parte del dominio que puede ser comprendida y utilizada de manera autónoma. Esta frontera ayuda a evitar ambigüedades, malentendidos y acoplamientos. Permite que los equipos de desarrollo se enfoquen en una parte específica del dominio.
- Context Mapping es un proceso en el que los equipos de desarrollo trabajan con los expertos del negocio para mapear los conceptos y procesos de negocios y establecer las fronteras de los diferentes Bounded Contexts. Un mismo concepto no tiene por qué tener el mismo significado en dos dominios, por lo que el contexto identifica el significado de ese concepto dentro de un dominio. Este proceso ayuda a identificar las relaciones entre los diferentes Bounded Contexts.
- Ubiquitous Language es un lenguaje común y coherente utilizado por todas las partes interesadas, incluyendo los expertos del negocio y los desarrolladores, para describir los conceptos y procesos de negocios. Este lenguaje ayuda a reducir malentendidos y a asegurarse de que todas las partes comprendan de manera consistente.
Definición de un modelo
Uno de los elementos clave de DDD es el modelo de dominio formado por las entidades, relaciones y reglas de negocio de un problema o necesidad del mundo real. Para la definición del modelo es importante la interacción entre los expertos de negocio y el equipo técnico siguiendo la regla de ubiquitous language comentaba en el punto anterior. Algunos de los elementos clave del modelo de dominio incluyen:
- Entities: Las entidades son objetos únicos y distintos que representan conceptos significativos en el dominio, como clientes, productos o pedidos. Cada entidad tiene atributos y relaciones con otras entidades.
- Values: Los valores son objetos que representan conceptos sin identidad en el dominio, como una dirección o una fecha. Los valores son inmutables y se usan para representar información que no cambia.
- Services: Los servicios son componentes que representan procesos o tareas que no son parte de una entidad o un valor en particular, pero que son importantes en el dominio. Los servicios se utilizan para implementar lógica que es demasiado compleja o no pertenece a una entidad o un valor en particular.
- Aggregates: Los agregados son colecciones de entidades y valores que representan una unidad coherente en el dominio. Cada agregado tiene una entidad de raíz que es la entidad principal.
Caso de uso
Veámoslo con un ejemplo, el diseño de un sistema de gestión de viajes para una aerolínea.
El equipo de desarrollo comenzaría identificando los distintos dominios o áreas de negocio dentro del sistema, como reservas, facturación, asignación de asientos, etc. Cada uno de estos dominios tendrá sus propias reglas y requisitos específicos. A continuación, se utilizaría el Ubiquitous Language para asegurarse de que todas las partes involucradas (expertos de negocio y equipo técnico) comprenden claramente los términos y conceptos específicos de cada dominio o subdominio. Por ejemplo, en el dominio de reservas, se podrían definir entidades como «pasajero», «reserva», «vuelo», etc. Una vez que se han definido las entidades, se puede comenzar a modelar el comportamiento y las interacciones entre ellas. Por ejemplo, se puede especificar cómo se realiza una reserva, cómo se asigna un asiento, cómo se factura un vuelo, etc. A partir de aquí, se podría comenzar a implementar el sistema, utilizando patrones de diseño y técnicas específicas de DDD para asegurarse de que el sistema se ajuste claramente a los requisitos y reglas de cada dominio.
Data Mesh y Domain-Driven Design (DDD)
Data Mesh es un enfoque para la gestión de datos que se basa en el Domain-Driven Design (DDD). La idea detrás de Data Mesh es que los datos se traten como un producto de software independiente, con sus propios equipos de desarrollo, su propia arquitectura y su propio ciclo de vida.
Un ejemplo para ilustrar esto podría ser una inmobiliaria. En este caso, siguiendo el enfoque DDD se identificarían los distintos dominios de negocio, como propiedades, compradores, vendedores, etc. Cada uno de estos dominios tendrá sus propios datos específicos, como descripciones de propiedades, información de contacto de compradores y vendedores, etc. En lugar de gestionar todos los datos en una arquitectura monolítica como un data warehouse o data lake, cada Dominio se encarga de crear y mantener sus propios conjuntos de datos conocidos como Data as a Product. Cada dominio estaría formado por los expertos de negocio y personal técnico. De esta manera, los equipos pueden centrarse en el desarrollo de los datos para su dominio específico, y el sistema en su conjunto se vuelve más escalable y fácil de mantener.
En resumen, en este ejemplo, Data Mesh utiliza DDD para dividir los datos en pequeñas piezas autónomas, permitiendo que los equipos se centren en el desarrollo de los datos para sus respectivos dominios de negocio.
