El libro escrito en el año 2003 por Eric Evans titulado Domain Driven Designs (DDD) contiene conceptos e ideas que han ganado más importancia a través de los años. Su visión sobre el viaje para crear Software sigue tomando adeptos y valor. ¿Qué tiene este libro para ser considerado una Biblia para algunos?
DDD como filosofía
No es un framework ni una práctica de desarrollo, es un viaje entre el equipo y un experto de un dominio del negocio. No es recomendado para todo tipo de proyectos y busca responder a una pregunta que siempre hemos tenido ¿Cuál es la mejor forma para desarrollar software?
Con la premisa de que lo más complejo en muchos proyectos software es entender el dominio, usando DDD nos concentramos primero en el problema.
El Dominio: explorando el problema
Los desarrolladores de software conocen varias formas de implementar una solución, a veces nos olvidamos que lo más importante es el problema y para eso se necesita colaborar estrechamente con alguien que conoce el dominio y que viva “el problema”, además de otros stakeholders interesados en ver soluciones. Mediante reuniones para explorar la visión del producto, la colaboración es vital para comprender lo esencial, es el primer paso para buscar una solución.
El equipo de desarrollo sale de sus tecnicismos y comienza a entender los conceptos, actores, ideas y procesos en un área. Las habilidades comunicaciones son imprescindibles para los desarrolladores que están usando DDD.
Un lenguaje común
El lenguaje común en DDD es conocido como Ubiquitous Language y es clave para lograr ese entendimiento entre el equipo de desarrollo y el experto de dominio. Ya no existen diferentes palabras con dobles interpretaciones. Los términos del negocio son reflejados en el producto Software, evitamos traducir para que alguien de otra área nos entienda buscando que el mismo código tenga sentido para todos ¿El experto de dominio será capaz de entender el código?
El experto de dominio, sin tener conocimientos técnicos sobre programación será capaz de entender, o al menos tener una idea sobre la implementación
El lenguaje común es traducido en código, en el nombre de sus atributos, métodos, clases y otras partes del software escrito. Los diseños de alto nivel o explicaciones del producto también utilizan los términos definidos en el lenguaje.
Entendiendo el mundo
Cada subdominio tiene un contexto y sus límites. En DDD las interacciones entre servicios y/o módulos en un dominio es conocido como Bounded Context.
El Bounded Context de un dominio es modelado para reconocer las relaciones de dependencia entre procesos ayudando a tomar decisiones estratégicas y técnicas entre quienes proveen los datos y quienes dependen de un subdominio en particular. Según el grado de la dependencia, hay una influencia sobre otros equipos. El patrón de la solución a implementar está definido por el contexto, nunca al revés.
Model driven design
Durante el descubrimiento del problema, buscamos entender cómo funcionan los procesos en un dominio específico, también encontramos las relaciones con otros productos y servicios en diferentes subdominios. El dominio es representado en un modelo, que es una abstracción del mundo real.
El modelo está compuesto por los actores, actividades y subprocesos, puede ser entendido por todos y mejora iterativamente. Después de construir un modelo inicial, ya estamos listos para seguir con el código.
La solución de software se implementa basándose en el análisis de modelos.
Arquitectura hexagonal
No es una obligación utilizarlo en DDD, es una recomendación para separar la lógica del negocio en el código de otros componentes externos técnicos como servicios API Rest o un repositorio.
Contiene principios que siempre son recomendables, SOLID y otros son su base. La arquitectura hexagonal se complementa con DDD favoreciendo la mantención del código.
Después la solución
Usando DDD una refactorización de aplicación solamente ocurre cuando hay cambios en los requisitos ¿No te has enfrentado con equipos refactorizando grandes porciones de software para un producto, resolviendo el mismo problema con diferente código? Después de entender el problema del dominio, podremos analizar el conjunto de patrones que nos pueden ayudar en la solución.
El experto de dominio ayuda a construir la solución y los diagramas resultantes ayudan a tomar decisiones informadas, además de entender mejor cómo el sistema está construido. Tú arquitectura estará alineada con el problema de dominio
DDD para problemas complejos
Debido a los costos en recursos y tiempo, es imprescindible analizar qué problemas vamos a resolver usando DDD. Los conocimientos técnicos del equipo y la complejidad del problema son determinantes para decidir si usarlo, tener un experto de dominio a disposición es fundamental.
Cuando quieras verificar que un equipo usó DDD en su producto, no puedes hacerlo mirando el código, ni los modelos, tampoco revisando la calidad de los diseños. Solamente quienes participaron en las reuniones, colaboraron en el lenguaje compartido, conocieron el problema y lo resolvieron pueden decírtelo.
DDD contiene prácticas útiles para todo proyecto, un glosario común, modelos de dominio y subdominios para entender lo que hay que hacer y una arquitectura de código útil para cualquier aplicación. No siempre vas a alinear a todos los equipos para usar las prácticas de DDD, toma lo que necesites si es necesario. Lo más importante es que un desarrollador de Software no solamente desarrolle código y ya dedica importantes cantidades de tiempo a vivir el problema y comunicarse con los usuarios. Reconoce que esas cualidades son más poderosas que ser un experto en frameworks o lenguajes de programación, hay otras prácticas que te llevarán al siguiente nivel.