Para la siguiente versión de qdoc, nuestro software de calidad, decidimos seguir la metodología Domain Driven Design. El DDD parece ser algo muy enfocado al diseño de un software, pero también puede aplicarse a otros contextos dentro de las empresas.

¿Qué es el Domain Driven Design?

El Domain Driven Design es una metodología para mapear, entender y resolver un problema dentro de una esfera de dominio. ¿Qué significa esto? El DDD busca hacer sentido entre las marañas de comunicación y procesos que tenemos como personas. A esto se le llamaría normalmente reglas del negocio o lógica del negocio.

Los sistemas tienden a replicar los patrones de comunicación. Utilizando técnicas como Event Storming o Story Mapping, podemos agrupar e identificar las secuencias de dicha comunicación. Es importante reconocer que, para poder realizar un cambio, debemos adecuarnos a los patrones existentes, en vez de imponer los nuestros.

El DDD tiene múltiples ventajas en el contexto del software, pero nos puede aportar valor en la forma en la que se administran nuestras empresas. Conforme estas crecen, se empiezan a superponer procesos y dependencias entre los mismos. Entender nuestros contextos, nos permitirá identificar las actividades núcleo, genéricas y de soporte.

Un ejemplo

Imagina el departamento de cotizaciones en una empresa de construcción. Para poder determinar el costo de un puente, el ingeniero civil debe hacer el cálculo estructural e indicar el grueso de las varillas; esta información se envía a la persona de compras, quien solicita las cotizaciones de los insumos. La información entonces viaja al departamento comercial, donde se establece el precio, no sin antes consultar con los administradores de proyecto para entender fases y tiempos de entrega.

Si quieres conocer como implementamos DDD en nuestro software qdoc de gestión de calidad, nuestros especialistas pueden ayudarte. Contáctanos.

¿Cómo se conforma un Dominio?

Un dominio, está dividido en subdominios más pequeños conocidos como bounded contexts. Un subdominio es una división lógica de un dominio en contextos más pequeños. Un bounded context es un espacio lógico en el que compartimos un lenguaje ubicuo. Es decir, en este espacio lógico, todos utilizamos las mismas palabras para referirnos a los mismos elementos.

Imagen: Martin Fowler

Ahora, a cada uno de los servicios no le interesa cómo haga el trabajo el otro contexto, sino las entradas y salidas; de esta manera, lo más importante es que cada uno de los contextos se pueda comunicar. Por ejemplo: en la gráfica de arriba, se puede ver que, para el contexto de “soporte”, no es relevante saber qué es una oportunidad, pero sí que el «cliente» sea el mismo para ambos contextos.

Lee también: 5 Consideraciones para definir un control documental

¿Qué aplicación tiene esto fuera de TI?

Tal vez si estudiaron negocios esto les sea muy parecido a la cadena de valor de Porter. Conociendo los contextos podemos determinar si es necesario que los realicemos de forma interna o si es recomendable externalizarlos con un experto.

En nuestro caso, cuando desarrollamos software, tener mapeados nuestros contextos nos permite reutilizar código o decidir si es necesario desarrollar un servicio. Existe funcionalidades que varios han resuelto anteriormente, y es más conveniente trabajar en lo que nos diferencia en el mercado.

Conclusiones

Identificar, reconocer y mapear nuestras organizaciones nos provee posibilidades para reducir la duplicidad de tareas, hacer más eficiente la comunicación y en caso de que se pudiesen automatizar procesos, hacerlo.

Es importante reconocer que los conceptos de Lean Manufacturing, Total Quality Management, Cadenas de Valor, Microservicios se hilvanan cada vez más. Este tema es muy interesante, y en caso de que deseen saber más les recomiendo el siguiente video: