Member-only story
Capítulo 1. Lo que aprendí de DDD. Conceptos básicos
DDD, Arquiectura Hexagonal, Event Sourcing, Lenguaje ubicuo…
Uno de los propósitos del año 2020 fue profundizar en el enfoque DDD y arquitectura hexagonal empleando mi framework favorito (Symfony) como punto de partida. Algunas de las ideas que extraje ya las he mencionado en el curso de Symfony que tenéis disponible en mi canal de Youtube.
Hoy comienzo una serie de artículos en los que daré forma a todas las notas que tomé durante el año pasado con el objetivo de acercaros un poco más las ideas fundamentales en las que se basa DDD.
¿Me acompañas?
¿Qué es DDD?
La idea del enfoque DDD (siglas de Domain — Driven — Design) es muy sencilla: alinear a todos los equipos involucrados en el desarrollo de un producto:
- Lograr una comunicación fluida y bidireccional entre el equipo de negocio y el de desarrollo.
- Asegurar que el producto desarrollado responde a las expectativas de negocio.
- Facilitar la iterabilidad y mantenibilidad del producto.
Esta es la razón de que en DDD el “lenguaje ubicuo” tenga tanta importancia. Definirlo al comienzo del desarrollo de un producto de largo alcance es el que nos permitirá que software y negocio trabajen bajo el mismo dominio de ideas.
Un ejemplo “tontorrón” en el desarrollo de un blog: el lenguaje ubicuo nos servirá para evitar que la parte de negocio hable de “artículos” mientras que el software tenga entidades llamadas “posts”.
¿Es DDD “el bálsamo de fierabrás”?
No, DDD no siempre es la solución óptima: este enfoque implica mucho más tiempo y una mayor implicación de todo el equipo que un desarrollo normal. Además, trasladar el dominio de negocio al software obliga a seguir determinados estándares que permitan portar esas ideas a las entidades y servicios de la aplicación. Quédate con esta idea:
DDD nos anima a acercar lo máximo posible la lógica de negocio a nuestras entidades de dominio.
Por tanto, antes de lanzarte a implementar un proyecto con una aproximación basada en dominio asegúrate de que…
