DDD es un enfoque del desarrollo de software que se centra en la programación de un modelo de dominio que tiene una rica comprensión de los procesos y reglas de un dominio.
¿Alguna vez has desarrollado o trabajado con un sistema de software que era "perfecto", aunque no permaneciera así durante mucho tiempo? Una vez que el esqueleto del sistema era sólido, las cosas eran más fáciles y la implementación de nuevas funciones parecía tan natural como encajar los ladrillos de Lego. ¿Qué fue lo que hizo que esa experiencia fuera tan mágica?
No era magia. Te dieras cuenta o no, el modelo en el código estaba en armonía con el dominio subyacente. Si eso es algo que quieres que ocurra siempre, el diseño orientado al dominio (DDD) es para ti.
¿Qué es el DDD?
Es un conjunto de ideas, principios y patrones que ayudan a diseñar sistemas de software basados en el modelo subyacente del dominio del negocio. El DDD tiene dos espacios distintos, el espacio del problema y el espacio de la solución.
En el espacio del problema, se define la estructura a gran escala del sistema con patrones estratégicos, que se centran en el análisis de un dominio, subdominios y lenguaje ubicuo.
Mientras que en el espacio de la solución, se adoptan patrones tácticos para proporcionar un conjunto de patrones de diseño que se pueden utilizar para crear el modelo del dominio. Estos patrones incluyen el contexto delimitado, el mapeo de contexto, las entidades, los agregados, los eventos de dominio, los servicios de dominio, los servicios de aplicación y la infraestructura. Estos patrones tácticos le ayudarán a diseñar microservicios que estén débilmente acoplados y cohesionados.
El principio unificador
Todos los sistemas de software que se han construido tienen un modelo en su corazón. Si este modelo encaja bien con el dominio subyacente, el software aceptará más fácilmente las mejoras y tendrá muchas más posibilidades de sobrevivir y prosperar intacto durante años.
El modelo puede no ser obvio; puede existir sólo en la mente de los desarrolladores, pero existe de todos modos. Los diseños elegantes son posibles en cualquier paradigma. Si el modelo reflejado en tu código está alineado con el dominio, el código fluye.
Es esta alineación lo que importa, y lograr y mantener la alineación es el propósito fundamental de DDD.
Siempre hay un modelo
Tu código tiene un modelo dentro de él. Si el código no es un modelo del dominio del negocio, entonces ¿Qué es? Si no está modelando intencionadamente el dominio, entonces ¿Qué está modelando accidentalmente en su lugar? Incluso en los mejores sistemas, tu código reflejará algunos aspectos del modelo de dominio bien en algunos lugares, pero no tan bien en otros.
Vamos con un ejemplo
Tu equipo está construyendo una aplicación que dará soporte a los clientes de SaaS, y tú estás interesado en el proceso de registro. La historia que el equipo está reproduciendo dice: "Como cliente, quiero poder registrarme para obtener una suscripción para poder utilizar el servicio". Miras el código y descubres que el método necesario está en la clase "cliente", lo que tiene sentido, pero que se llama CreateCustomer
Ouch.
Sí, la funcionalidad del método llamado CreateCustomer hace todo lo necesario para completar el registro de un cliente, pero el lenguaje que utiliza describe su propia implementación, no la actividad del dominio. Nombrar el método SignUpForSaaSSubscription reflejaría mejor la actividad real del dominio y dejaría clara la intención del método.
A un nivel trivial, se trata de los nombres que se utilizan para las cosas. A un nivel superior, se trata de la forma en que se combinan y activan las cosas para producir valor empresarial.
En el nivel superior, es el modelo causal y de relaciones (semántico) que mantiene todo cohesionado, coherente y alineado con el negocio. Esta alineación no puede provenir de un modelo centrado en la implementación. Hay que utilizar un modelo de dominio.
Un modelo aplicable al negocio no tiene que estar redactado en términos DDD para ser bueno. Si tu modelo de negocio está descrito de forma natural y completa por un modelo de operaciones de base de datos de creación, lectura, actualización y eliminación (CRUD), entonces es suficiente. Lo que importa es la alineación, y el objetivo es la alineación continua.
Beneficios
La adopción de DDD puede proporcionar muchos beneficios, como una comunicación clara entre todos los equipos y un patrón maduro para gestionar la complejidad y proporcionar una mejor escalabilidad al diseñar el sistema, por ejemplo:
- Con los lenguajes ubicuos, podemos lograr nombres de clases y de funciones más autodescriptivos.
- Con el patrón de agregación, podemos lograr límites claros y una sola responsabilidad.
- Con el patrón de eventos de dominio, podemos dividir los procesos empresariales centrales con efectos secundarios en los agregados.
- Con el patrón de capa de infraestructura y ACL, podemos separar el modelo de dominio de negocio central de los detalles de implementación técnica.
- Con el patrón de contexto acotado, podemos derivar los potenciales candidatos a microservicio.
Desafíos y lecciones
Hay algunos retos y lecciones que queremos compartir al aplicar DDD en la práctica:
- El DDD es una colección de patrones complejos que lleva mucho tiempo que todo el equipo aprenda y entienda, pero los beneficios para el diseño de su sistema hacen que merezca la pena.
- DDD no proporciona un marco de trabajo sobre cómo aplicarlo en la práctica.
- El DDD sólo es adecuado para el diseño de sistemas complejos y, por tanto, no puede aplicarse a todos los proyectos.
Conclusión
El patrón DDD es un tema muy amplio (y es imposible cubrirlo en detalle), pero queremos presentar algunos de los temas críticos y nuestra experiencia en la práctica del patrón.
En el futuro, seguiremos profundizando en cada tema del patrón DDD, como la gestión de capas, el almacén de eventos de dominio, el patrón de mapa de contexto, entre otros, y cómo aplicarlos en el diseño del sistema.