Si participas en el sector del desarrollo de software, probablemente estés de acuerdo en que entender un negocio es tan o más importante que el saber programar bien. Partiendo de esta premisa, el mejor paradigma para enfocarse en el negocio y plasmarlo en el código es aplicar el modelo DDD (Domain Driven Design).
Este enfoque de desarrollo de software propuesto por Eric Evans pone en el centro al dominio del negocio. Pero, ¿qué es el dominio? Básicamente, representa la información, la lógica y procesos del negocio. Así como el problema específico que debemos resolver.
El DDD está concebido para facilitar el desarrollo de aplicaciones complejas y para aquellos proyectos que utilizan metodologías agile. Del mismo modo, no servirá para proyectos en los que se utilizan conceptos exclusivamente técnicos y poca lógica de negocio.
Todo el conjunto de elementos significativos que representan el dominio (atributos, funciones y relaciones), así como el conocimiento que se tiene sobre este, se verán representados en el modelo. Este será la base del diseño del software y se irá depurando a medida que se aprenda más sobre el dominio.
Si queremos que el desarrollo de las aplicaciones tenga éxito, deberá existir un lenguaje común (Ubiquitous Language) entre los expertos en el dominio, conocedores del negocio, el flujo y la operativa a seguir para resolver el problema, y los desarrolladores. Se deberán tener claros los conceptos del negocio para construir las entidades y las relaciones entre ellas. De esta manera, la estructura y el lenguaje en el código del software (nombres de entidades, propiedades y funciones) serán un reflejo del dominio de negocio.
Conocer en profundidad el dominio evitará errores funcionales y, en caso de tener que explicar nuevas funcionalidades o relaciones que se deben aplicar durante el proyecto, la comunicación entre ambas partes será más inteligible. También facilitará el mantenimiento del modelo y permitirá concebir un software con los objetivos bien claros.
Como resultado, obtendremos un código limpio, donde los comentarios servirán para aclarar los conceptos y explicar cuál es la funcionalidad del bloque. No necesitaremos incluir ningún diccionario para identificar las entidades en los comentarios.
Elementos clave
El Domain Driven Design se compone de los siguientes elementos:
Entidades:
En las entidades se definen todos los modelos que el negocio necesita para representar. Las entidades son objetos con identidad única, que se mantiene en el tiempo y cuyos atributos no son su principal característica.
Objetos de valor:
A diferencia de las entidades, los objetos de valor no tienen identidad y se definen únicamente por los valores de sus atributos.
Contexto:
El conjunto de entidades que están relacionadas entre ellas y que deben coexistir conjuntamente para que el negocio tenga sentido.
Servicios:
Toda la lógica del negocio vive en este bloque. Los servicios no tienen ninguna dependencia con ninguna parte externa del negocio (por ejemplo, acceso a base de datos).
Repositorio:
Los repositorios deben contener la implementación de los accesos de los datos externos. Implementan las interfaces de los servicios del dominio.
La documentación de las aplicaciones es importante tanto para el cliente como para el desarrollador. La documentación es un doble factor para verificar que la aplicación realiza las operaciones y en la secuencia correctamente.
Aunque es un proceso que requiere de tiempo de aprendizaje y gran implicación por parte de los equipos involucrados en el proyecto, Domain Driven Design te permitirá tener una mayor visión y enfoque del negocio. Así, se conseguirá un software cercano al cliente, con un código bien organizado y fácilmente mantenible en el tiempo.
En Click-IT empleamos DDD para afrontar proyectos de desarrollo complejos. Cuéntanos tu necesidad y te ayudaremos a encontrar la mejor solución que cumpla tus objetivos.