¿Qué es eso del diseño guiado por dominio y el principio de arquitecturas limpias? En esta serie de posts, os contamos en qué consiste, por qué nos gusta y cómo aplicarlo. En este nuevo post, nos ponemos manos a la obra para modelar una funcionalidad específica siguiendo filosofía DDD.

En el anterior post de esta serie sobre arquitecturas limpias y DDD, se introdujeron los conceptos básicos sobre dicha arquitectura y se discutió sobre la filosofía de diseño separada en capas, sus elementos y características fundamentales y por supuesto sobre las ventajas de su uso.

Llegados a este punto, cabe preguntarse cómo pasar a la acción. Dicho de otro modo, planteado un problema funcional o un caso de uso a implementar, ¿cómo aplicar DDD? A lo largo de este y de los siguientes posts de la serie, se tratarán los siguientes puntos al respecto:

• Planteamiento de un problema funcional real.
• Aplicación y uso de lenguaje ubicuo.
• Diseño estratégico de la solución.
• Diseño táctico e implementación.

Problema: control de operaciones en manufactura

Tomemos como ejemplo un problema de digitalización característico de una empresa manufacturera y su flujo de producción, donde los operarios deben realizar ciertas tareas para acabar una orden de trabajo que, en última instancia, permite fabricar un producto.

La forma de trabajo habitual de los operarios es la siguiente:

• De cada orden de trabajo que les facilitan, toman una o varias de las operaciones que deben realizar, según sus conocimientos y certificaciones, y comienzan a trabajar en ellas.
• Marcan la tarea como asignada al operario y en progreso, para que nadie la tome de nuevo.
• Una vez acabada la tarea, la marcan como finalizada y vuelven al principio del proceso.

Cabe destacar, como restricción, que las operaciones sólo pueden encontrarse en un estado a la vez, es decir, o están por hacer, o están en proceso o están finalizadas. De manera resumida, su flujo es el siguiente:

¡Veamos como podemos implementar este problema!

Nuestro aliado el lenguaje ubicuo. Conceptos de negocio

The use of language on a project is subtle but all-important […] to create a supple, knowledge-rich design calls for a versatile, shared team language, and a lively experimentation with language that seldom happens on software projects.

 

Eric Evans – Domain-driven design. pp.23 – 24.

Una de las partes más importantes de DDD es el lenguaje. De las sesiones del equipo (equipo de desarrollo y expertos del dominio, se entiende) debe emerger un lenguaje consensuado entre todos que explique el modelo de forma unívoca. Para ello, hay que prestar especial atención a lo que nos comunican los propios expertos del dominio.

Para este ejemplo en particular, tomaremos la explicación anterior como la información que tenemos del dominio (imaginemos que ha sido un experto quien nos la ha facilitado) y extraeremos, de manera somera, los conceptos y entidades más importantes:

• Operario. Usuario técnico que ejecuta las operaciones. Cada operario tiene habilidades (skills) que les permitirá o no ejecutar una operación.
• Orden. Una orden de trabajo es el conjunto de operaciones que uno o varios operarios deben llevar a cabo para producir un bien o servicio, dado unos recursos consumibles.
• Operación. Las operaciones son la unidad mínima de trabajo que un operario debe ejecutar para conseguir acabar una orden de trabajo. Todas las operaciones pertenecen a una orden concreta, deben ejecutarse por operarios con los skills necesarios y son cambiadas de estado durante el flujo de trabajo del operario. Pueden encontrarse en 3 estados diferentes: TODO, DOING y DONE.

Diseño estratégico: la hora de la verdad

Durante la etapa de diseño estratégico el equipo de desarrollo, junto con los expertos del dominio, deben definir los bounded contexts, el lenguaje ubicuo y los context maps que expliquen el dominio del problema.

Para ello es recomendable seguir, entre otras, la técnica de Event Storming. Con esta técnica podemos definir qué comportamiento existe en nuestro dominio, qué elementos intervienen y cómo se relacionan entre ellos. Toda esta información posteriormente ayudará a determinar los building blocks de nuestro proyecto software.

Continuando con el ejemplo planteado, en la imagen siguiente se puede ver un modelado de cambio de estado de operaciones.

De esta imagen y su análisis, y siguiendo la nomenclatura de Event Storming, se puede obtener suficiente información del dominio como para realizar una primera implementación. Pero eso lo dejaremos para el siguiente post.

En el próximo capítulo de esta serie, se llevará a cabo el diseño táctico y la implementación de la solución.