¿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.
Arquitecturas limpias y DDD, un recorrido práctico. Parte 2
Arquitecturas limpias y DDD, un recorrido práctico. Parte 2
Arquitectura | DDD | Desarrollo
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.
¿Quieres dar el primer paso en digitalización? Llámanos sin compromiso y diseñamos tu Mínimo Producto Viable
Aquí tienes más
blogs, noticias y eventos
Arquitecturas limpias y DDD, un recorrido práctico. Parte 2
leer más
Digitalizar en plano secuencia
No se debe tener miedo ni duda al afirmar, simplemente por ser, en apariencia, un concepto opuesto al frío tecnológico, que la digitalización trata de emociones. Digitalizar en plano secuencia es cubrir expectativas y aportar alegría a nuestros clientes.
El papel de la protección de datos en tiempos de teletrabajo
Desde la incorporación masiva del teletrabajo, se ha conformado un nuevo escenario de riesgos en materia de seguridad y protección de datos que exige por parte de las empresas una gestión adecuada que garantice su integridad de acuerdo a las leyes vigentes. Hablemos sobre el papel de la protección de datos en el teletrabajo.
