En 2021 inicié un apasionante proyecto de transformación digital, proceso bastante complicadete, que puedo decir ya va en modo «automático».
Este proceso tiene como punto de partida un sistema monolítico, junto con otros satélite que lo acompañan (también monolitos), sistema que no permite alcanzar los objetivos empresariales por sus limitaciones frente las exigencias actuales del negocio.
Se establecieron 2 vectores de cambio (la modernización de aplicaciones y las aplicaciones compuestas y se vio la necesidad de determinar una batería de arquitecturas de referencia. Y topamos con la primera piedra: ¿cómo organizaremos y estructuraremos los artefactos que se vayan elaborando? Veamos qué es eso de la organización Domain-Driven y de cómo Domain-Driven Design puede ayudarnos.
¿Qué es Domain-Driven Design?
Para hablar de una organización dirigida por dominio (organización Domain-Driven), hay que acudir al concepto de diseño orientado por dominio (Domain-Driven Design o, para abreviar, DDD).
No voy a abordar en este artículo qué es DDD, ni cómo se usa, aunque aterrizaremos el concepto. Quien acuñó el concepto es Eric Evans; si lo que quieres es aprender sobre el tema, te aconsejo leas su libro “Domain-Driven Design: Tackling Complexity in Software,” Addison-Wesley 2004.
DDD es un conjunto de principios y patrones que ayudan a arquitecturar, crear y relacionar sistemas de información, y que llevan a la abstracción del software basado en lo que se denominan modelos de dominio. Cada modelo de dominio es una representación abstracta y conceptual de un área de negocio (dominio) que captura la complejidad y funcionamiento del negocio, su comportamiento, sus reglas, entidades y relaciones, siempre dentro de un contexto específico y acotado.
Debemos tener en cuenta que:
- Domain Driven-Design; tiene, por así decirlo, unas fronteras que lo separan y distinguen de otros dominios, como los países en un mapamundi. A esto le llamamos Bounded Context o contexto acotado. Es la forma en que DDD divide un dominio complejo en partes más pequeñas, manejables y con entidad propia y significativa desde el punto de vista del negocio.
- Cada contexto acotado maneja unos términos y conceptos; tiene un lenguaje específico, lo que se denomina Ubiquitous Language o lenguaje ubicuo. Así pues, los dominios manejan sus propios conceptos y éstos son subjetivos y no son mutuamente excluyentes (los mismos conceptos pueden existir en distintos dominios). Idealmente, un contexto acotado debería ser lo más autónomo posible e independiente de otros… ¡ya huelo a microservicios! 😉
Objetivos
Los objetivos que nos marcamos y que nos llevaron a la aplicación de DDD en las arquitecturas de referencia fueron:
- Desacoplar la lógica de negocio en base a áreas de conocimiento, de interés, funcionales, temáticas, de responsabilidad o de actividad (dominio de negocio).
- Alinearnos con las «capabilities» (capacidades) empresariales, que describen la habilidad de una organización para realizar una función o un proceso específico y que son agnósticas a la tecnología y a la estructura organizativa.
- Disponer de un modelo de organización, adscrito al negocio, estable en el tiempo.
- Migrar de un modelo de datos (el del monolito) que representa a toda la empresa en favor de varios modelos de datos que dan cobertura a distintos subdominios, en el que cada subdominio puede tener datos que le son propios y otros que sean los mismos que en un subdominio diferente.
- Acercar la semántica y el lenguaje utilizado en el modelo al usado por el negocio en cada subdominio (contexto).
Atendiendo a que uno de nuestros vectores del cambio eran las aplicaciones compuestas, la cosa ya apuntaba a que íbamos a una arquitectura de microservicios y, por tanto:
- Cada objeto del modelo de dominio (componentes fundamentales que construyen y representan el modelo de dominio, es decir, las piezas que encapsulan la lógica de negocio y los datos del área de negocio que estás modelando) puede convertirse en un microservicio.
- Si el modelo de dominio contiene objetos muy relacionados entre sí, éstos pueden agruparse en un único microservicio, donde cada objeto del modelo de dominio acaba siendo un módulo independiente dentro de ese microservicio.
- Los objetos del modelo de dominio pueden convertirse en módulos de una aplicación.
- Cada objeto del modelo de dominio puede convertirse en una o más entidades en base de datos.
- En la orientación a objetos podemos desglosar el modelo de dominio en un diagrama de clases (aunque esto es realmente diseño de software, no arquitectura de software) donde cada objeto del modelo de dominio se convertirá en una o más clases de software relacionadas.
Organizando, que es gerundio
Me gusta tener la cosas ordenadas, organizadas, y DDD lo estoy usando, entre otros, para organizar artefactos.
Artefactos
Un artefacto es cualquier elemento tangible o intangible producido durante el proceso de diseño arquitectónico. Estos artefactos pueden ser documentos, diagramas, modelos, componentes de software, entidades de datos, tópicos, o cualquier otro elemento que contribuya a la creación, entendimiento, mantenimiento o despliegue de un sistema.
En esencia, los artefactos son los productos del trabajo realizado por los arquitectos, y sirven como medio para comunicar, documentar y construir el software.
DDD puedes tomarlo como una propuesta de cómo estructurar artefactos según el espacio del problema que tratan de solventar, organizando conceptos, funcionalidad, información, etc, y para eso lo primero que se hizo fue determinar las taxonomías bajo las cuales organizar todo el tinglado.
Taxonomía
Taxonomía proviene del griego «taxis», ordenación, y es la
ciencia que trata de los principios, métodos y fines de la clasificación. Se aplica en particular, dentro de la biología, para la ordenación jerarquizada y sistemática, con sus nombres, de los grupos de animales y de vegetales.
— Real Academia Española
Cuando defines tus dominios, subdominios y contextos acotados, estás creando una estructura lógica y de negocio para tu organización. Esta misma estructura puede usarse para organizar tus artefactos.
Los contextos acotados son las unidades naturales de organización. Cada contexto acotado encapsula un área coherente del negocio con su propio lenguaje ubicuo y modelo de dominio. Esto los convierte en categorías de primer nivel ideales para organizar todo lo relacionado con esa parte del sistema.
Dentro de cada contexto acotado podemos usar subdominios o los agregados principales como subcategorías. Los agregados, al ser unidades transaccionales y de consistencia, agrupan la lógica y los datos relacionados.
Adicionalmente, y para acabar de rizar el rizo y organizar hasta los propios dominios, establecimos 2 tipologías de dominios:
- Core: los que generan negocio, generan valor.
- Supporting: elementos coadyuvantes a los core, sin generar valor, que realizan funciones importantes, pero de apoyo al core.
El paraguas
DDD sirve, gracias a la definición de taxonomías, como un paraguas bajo el que poder disponerlo todo de forma ordenada y sí, cuando digo todo es todo:
- Estructuramos los repositorios de código en base a DDD.
- Clasificamos los microservicios en base a DDD.
- Organizamos los contratos de las APIs en base a DDD.
- Montamos los namespaces de Kubernetes en base a DDD.
- Nombramos los tópicos de Kafka en base a DDD.
- Establecemos los scopes de los tokens de autorización en base a DDD
- Damos nombre a los componentes desplegables sobre Kubernetes en base a DDD.
- Etc.
Ese paraguas constituye un Modelo de Referencia basado en DDD y, en mi opinión, debería ser lo primero que deberías abordar si te ves enfrascado en un proceso de cambio absoluto de paradigma arquitectónico como es el caso que llevo ya algunos artículos relatando.
Conclusión
Las cosas requieren orden, no caos, y van a ser muchos los artefactos que, como arquitecto, vas a generar. Esos artefactos necesitas colocarlos en el cajón adecuado y así tener todo bien organizado.
DDD puede ser un arma poderosa para crear una taxonomía y organizar artefactos. Seguramente no fue concebido teniendo la organización de artefactos en mente, pero nos proporciona un beneficio secundario brutal. Al uso de DDD a la hora de estructurar, nombrar o clasificar arqtefactos de arquitectura le denomino una organización Domain-Driven.
Sí, lo sé, no te he dado ni un maldito ejemplo de cómo he organizado el cotarro. ¿Esperabas un árbol representando esa estructura organizativa? ¿Esperabas ese modelo de referencia? No desesperes, que lo vas a tener pero, por aquello de aumentar las visitas y tener más que el blog de fontanería de mi vecino, lo dejo para el siguiente artículo.