Domain Driven Design: una idea general

Me parece buena idea, para mi DDD es algo pendiente ya que mi conocimiento es muy muy muy básico por decirlo de alguna forma.

Para los desarrolladores o conocedores de PHP recomiendo el libro Domain-Driven Design in PHP12.

Otro recurso interesante es este video de Carlos Buenosvinos: https://www.youtube.com/watch?v=dDofYAOkpts12

Y esta playlist con charlas (la mayoría en castellano) https://www.youtube.com/playlist?list=PLfgj7DYkKH3DjmXTOxIMs-5fcOgDg_Dd210

Sin profundizar creo que es importante no confundir DDD con "la arquitectura por capas" que propone la Arquitectura Hexagonal. Podríamos decir que DDD se basa en la Arquitectura Hexagonal como pilar central en términos de arquitectura pero no es lo mismo.

Hola, ¿con cuál de estos libros es mejor empezar?

Rojo (Implementing Domain-Driven Design)
Azul (Domain-Driven Design: Tackling Complexity in the Heart of Software)
Verde (Domain-Driven Design Distilled)
PPPD (Patterns, Principles, and Practices of Domain-Driven Design)

Para una idea general, el distilled está bien.

Yo me estoy leyendo el Patterns, Principles, and Practices of Domain-Driven Design y me está gustando (más que el rojo de Vernon), pero yo soy muy fan de Nick Tune.

Por otro lado, pq dices que el boom de DDD ha pasado? Actualmente hay tres conferencias importantes a nivel mundial, una montada el año pasado y otra montada este año. Y la DDD eXchange goza de una buena salud, se dan un montón de cursos de DDD, event storming, CQRS, etc...

Voy a hacer un intento aportando mi punto de vista:

¿Qué problema intenta resolver DDD?

Algo tan "sencillo" como poder desarrollar software que perdure y evolucione en el tiempo, entregando valor a los usuarios sin que sea necesario plantearse cada X meses/años una historia habitual: "esto es insostenible, tenemos que rehacerlo todo"

¿Cómo intenta resolverlo?

Proporcionando una serie de recetas tanto en el ámbito técnico (patrones tácticos) como en el del negocio (patrones estratégicos). Estos patrones nos ayudan a trabajar con los expertos del dominio modelando el problema (definición de los dominios, subdominios, bounded contexts, agregados, lenguaje ubícuo, etc) y modelando la solución (arquitectura hexagonal, CQRS, Event Sourcing, etc. ojo! son sólo ejemplos!)

Para mi la parte más importante está en que nos guía para centrarnos en lo que realmente importa, el negocio. Intentando que nuestro foco esté en prestar atención a la complejidad del problema (negocio, dominio) y no de la solución (implementación tecnológica)

¿Qué conceptos clave maneja?
Desde el punto de vista del dominio, para mi los fundamentales son: lenguaje ubicuo y bounded context. Maneja más, pero sólo con esos ya tenemos para rato

Desde el punto de vista técnico, para mi lo más importante es que se centra en que separemos el dominio de todo lo demás. De ahí que se recomiende la arquitectura hexagonal.

¿Qué características debe tener un proyecto para que sea interesante aplicar DDD?

Algunos indicadores para mi son:
* Si tenemos un dominio complejo
* Si no tenemos ni idea del dominio que tenemos pero sabemos que vamos a tener muchos procesos, historias de usuario, etc.
* Si se trata de un proyecto con proyección a varios años vista (con dominio, claro).

He escuchado alguna vez asociarlo al tamaño del equipo de desarrollo, personalmente no empatizo con esa idea.

¿Cuando NO se nos debe ni pasar por la cabeza aplicar DDD?

No me gusta responder forma absoluta a estos temas, pero diría que cuando no tenemos dominio. Por ejemplo, si estamos haciendo un cliente de Twitter o de Git, un Paint o algo así, creo que no tendría mucho sentido. Podría decir que cuando toda nuestra aplicación en mecanismo de entrega en si misma.

Tampoco tiene mucho sentido para aplicaciones data-centric. Aunque claro, creo que muchas veces convertimos problemas de dominio complejo en aplicaciones data-centric simplemente porque tendemos a desarrollar cruds.

Eso no impide que busquemos algo tan útil como tener un lenguaje ubicuo en nuestra aplicación Pero entiendo que es más un tema de coherencia que de decir "estoy usando una parte de DDD"

Creo que en su momento hubo algunos sectores en los que se generó hype con DDD (para variar) pero nada que no suela ocurrir, pq parece que no aprendemos

Lo que no me atrevería a decir es si DDD ha cruzado el abismo6 o no, creo que no es adecuado medirlo en esos términos.

Yo cuento como está siendo mi experiencia aprendiendo y buscando la luz con DDD (o algo parecido).

Las lecturas y vídeos que estoy siguiendo principalmente son los de Carlos Buenosvinos. Lo explica todo muy bien, con muchos ejemplos y de forma muy amena, además, me es muy familiar todo porque su contexto es el desarrollo web y yo me dedico también a ello.

Ahora mismo estoy en el punto en el que la teoría más o menos la entiendo, pero llevarlo a la práctica me resulta bastante complejo. No veo que sea algo inmediato de decir me leo los libros y me pongo de forma rápida. De hecho, me ha resultado tan complejo que he cambiado de enfoque de un DDD puro a implementar primero arquitectura hexagonal, que son parecidos, pero no. Con los conceptos aprendidos en DDD la arquitectura hexagonal me está resultando un poco más 'fácil' de implementar.

Como digo, para mi lo difícil es llevarlo a la práctica. En otro de los vídeos de los tantos que he visto, uno de Adoración González en el PHPMadrid en el que habla de arquitectura hexagonal, soltó así como quién no quiere la cosa una frase que para mi ha supuesto un cambio radical en mi forma de pensar sobre como construir aplicaciones. Dice algo así como "...empieza a construir tu aplicación sin framework, sin base de datos...implementando primero el dominio...". Para mi, acostumbrado de manera mecánica a empezar una aplicación precisamente poniendo en primer lugar el framework y el orm entre otras cosas, me ha hecho cambiar el chip y sobre todo a encajar y entender la filosofía y muchos de los conceptos aprendidos con DDD y arquitectura hexagonal.

Si tuviera que recomendar algo a quién quiera empezar con toda esta jaleo, recomendaría que, si pudiera, encontrara a alguien que ya tenga experiencia y que le muestre ejemplos prácticos y reales de código que funcione con estos enfoques. Un ejemplo real vale mucho más que mucha teoría.

En fin, veremos a ver como acabo con todo esto...que todavía estoy a tiempo de volver Cobol.

Aunque llevo tiempo intentando hacer DDD en algunos proyectos en producción me considero nuevo porque nunca he trabajado con alguien que tenga experiencia en DDD. Para mi lo que he aprendido hasta ahora clave es:

¿Qué problema intenta resolver DDD?

Yo creo que casi lo mismo que la programación orientada o objetos (que creo que muchas veces se hace mal), y es modelar lo que quiere el cliente con las palabras del cliente (dominio). Para mi un código es DDD si lo lee un project manager que no sea programador y lo entiende. Ya se que es un definición un poco "cutre" pero creo que refleja la intención.

Esto permite que el código evolucione fácilmente con el negocio.

¿Cómo intenta resolverlo?

Usando en el código el mismo lenguage de la gente de negocio (y para ello quitando del código todo lo que no sea negocio).

¿Qué conceptos clave maneja?

Para mi (hasta ahora) el concepto clave es el de agregado. Un buen diseño de agregados es lo que marca la diferencia y es lo que realmente es difícil de hacer. Y estos tres artículos:

https://vaughnvernon.co/?p=8383

son la clave para entender como hacer un buen diseño (pero hay que leérselos 300 veces como mínimo). Yo he empezado hasta a traducirlo al español para entenderlos mejor:

¿Qué características debe tener un proyecto para que sea interesante aplicar DDD?

Mucha gente dice que para dominios complejos que no sean CRUD. Pero también he leído gente que dice que puede ser útil siempre y gente que dice que realmente no hay CRUDs. Yo también creo que nunca he hecho realmente un CRUD (ni siquiera con ACCESS :-), cualquier cosa que dure más de 1 mes deja de ser un CRUD rápidamente).

¿Cuando NO se nos debe ni pasar por la cabeza aplicar DDD?

Cuando tu aplicación sea un CRUD :-). Pero asegúrate que lo sea.
En los proyectos que hemos intentado aplicar DDD, lo que sí hemos visto es que a lo mejor no interesa aplicarlo a todo, sino a la parte core de negocio o no desde el principio, aunque hacer un refactor a posteriori suele ser algo que no se hace.

Para los que sean de PHP, un recurso bueno (a parte de libro y videos de Buenosvinos, que ya han puesto) es este foro:

• https://groups.google.com/forum/#!forum/dddinphp

También está esta web:

• http://dddcommunity.org/2

Lo difícil es ponerlo en práctica.

Y finalmente listado de aplicaciones (en PHP):

• https://github.com/dddinphp/last-wishes
• https://github.com/dddinphp/IDDD_Samples_PHP1
• https://github.com/codeliner/php-ddd-cargo-sample
• https://github.com/citerus/dddsample-core
• https://github.com/leopro/trip-planner2
• https://github.com/igorw/doucheswag
• https://github.com/josecelano/ddd-symfony-sample1
• https://github.com/josecelano/ddd-laravel-sample

Hay otros con Event Sourcing, pero todavía no me he atrevido con eso en producción.