Capítulo sobre DDD en un libro en español

[jmbeas]

Hola a todos,

Me han invitado a colaborar en un libro con un capítulo sobre DDD en
español. Quería pediros vuestra colaboración para que me indicarais
qué es lo que os parece más relevante que DDD aporta.

Muchas gracias,
JMB

[Carlos Peix]

Hola Pepe,

Mis felicitaciones.

Es dificil decirlo sin conocer la orientacion del libro, por ejemplo, el libro de Evans y el de Nilsson difieren bastante.

Yo encuentro en la comunidad .NET (en Argentina) que aun no logra convencerse de que DDD puede ser aplicado confiablemente en el trabajo del dia a dia.

Hay mucho codigo escrito desde los principios de .NET basado en el patron Business Entity/Business Component (tal como lo definio Microsoft) y, como es logico, muchos siguieron (seguimos) esa linea porque era lo unico que conociamos.

Esto condujo a una situacion compleja ya que hay una inmensa base de codigo escrito de esa manera que funciona, cambiar a algo que "probablemente" funcione mejor es complejo.

No se si la comunidad Java tiene ese problema pero, en todo caso, descuento que es menos acentuado.

Creo que los patrones basicos de DDD ya estan descriptos en el libro de Evans y el libro de Nilsson profundizo en implementacion (aunque no estoy seguro de que haya sido un libro eficaz).

En concreto, creo que seria bueno hacer esfuerzos orientados a presentar DDD como tecnica de todos los dias, a despojarla de ese halo de "tecnica de academia".

Un saludo

----------------------------------
Carlos Peix

2009/9/28 jmbeas <jose....@gmail.com>

[José Manuel Beas]

Sí, claro, los "javeros" tenemos más o menos el mismo problema con los
patrones J2EE.

Yo personalmente veo muy atractiva la arquitectura que proponen Greg
Young o Udi Dahan para implementar "DDD en el mundo real" (esto lo
digo yo). La separación entre consultas y comandos (CQS) y separar
ambos lados con un anticorruption layer hace que todo sea mucho más
sencillo y eficiente.

Para mi, todo gira, conceptualmente hablando, en torno a la idea de
que diseñamos a partir del dominio en vez de en torno a los datos. En
este sentido, tengo un poco de reparo al ver todos aquellos sistemas
que se están construyendo con el patrón Active Record, que es muy
"database o datamodel centric".

Pero claro, es necesario, para quitarle ese "halo" tener quizás una
arquitectura "de todos los días" de referencia.

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com




2009/9/28 Carlos Peix <carlo...@gmail.com>:

[Carlos Peix]

Hola Jose,

Hablando de CQS (y de DDDD por añadidura), yo lo encuentro aun mas intimidante para el que recien comienza. Yo mismo tengo mis reparos para aplicarlos en aplicaciones DDD "normales".

Personalmente aprecio el beneficio de mantener al dominio "encerrado" y dejar pasar solo los mensajeros pero aun no veo la justificacion de la sobrecarga de trabajo necesaria para escribir cada command y los DTOs.

Te dieron opciones para el tema del capitulo?

----------------------------------
Carlos Peix

2009/9/28 José Manuel Beas <jose....@gmail.com>

[José Manuel Beas]

2009/9/28 Carlos Peix <carlo...@gmail.com>:

> Hola Jose,
> Hablando de CQS (y de DDDD por añadidura), yo lo encuentro aun mas
> intimidante para el que recien comienza. Yo mismo tengo mis reparos para
> aplicarlos en aplicaciones DDD "normales".
> Personalmente aprecio el beneficio de mantener al dominio "encerrado" y
> dejar pasar solo los mensajeros pero aun no veo la justificacion de la
> sobrecarga de trabajo necesaria para escribir cada command y los DTOs.

Bueno, se supone que es porque así escala. Cuando hablamos de "SOA de
verdad", de alguna manera nos vemos empujados a pensar en DDDD.

En cuanto a sobrecarga de trabajo, los command los tienes igual (sólo
que separados "físicamente" de las consultas). Los DTOs simplemente me
parece una buena práctica porque supongo que lo dices porque tú usas
los propios objetos del dominio en la UI (estilo NakedObjects o algo
así), ¿no?

Yo necesitaría un par de buenas sesiones para que alguien me
convenciera (con código en la mano) de que usar los objetos del
dominio en la UI es más mantenible que usar DTOs y tenerlo todo bien
desacoplado.

> Te dieron opciones para el tema del capitulo?

No, de hecho el libro es sobre TDD, pero el autor (cuidado, anda por
aquí, je, je) me ha pedido un capitulillo introductorio a DDD porque
pretende incluir capítulos similares de otros temas no necesariamente
relacionados. Yo había pensado el siguiente esquema:

1) Intro histórica, el libro de Evans y poco más
2) Conceptos básicos: lenguaje unificado, dominio, entidad, servicio,
repositorio, capa anticorrupción...
3) ¿Por qué con DDD podemos construir mejores sistemas? Respuesta:
porque son más fáciles de comprobar. Aquí podría hablar de la
"ignorancia de la persistencia" en los repositorios y la relación con
la inyección de dependencias.

Y con esto creo que sería más que suficiente para un capitulillo
introductorio a DDD. ¿No les parece?

Un saludo,
JMB

[Carlos Peix]

2009/9/28 José Manuel Beas <jose....@gmail.com>

Bueno, se supone que es porque así escala. Cuando hablamos de "SOA de

verdad", de alguna manera nos vemos empujados a pensar en DDDD.

Es cierto, es la manera de escalar. Pero, en historia son pocas las aplicaciones en las que he necesitado esta "infraestructura". Muchas de las aplicaciones que escribo funcionan perfectamente bien en un servidor. No hay dudas que si es necesario escalar, CQS y DDDD es un muy buen camino para DDD

 

En cuanto a sobrecarga de trabajo, los command los tienes igual (sólo
que separados "físicamente" de las consultas). Los DTOs simplemente me
parece una buena práctica porque supongo que lo dices porque tú usas
los propios objetos del dominio en la UI (estilo NakedObjects o algo
así), ¿no?

Exacto, aunque no necesariamente en las mismas condiciones que NO, simplemente bindeo los objetos directamente en la UIo, como mucho, hago algun DTO especifico para "aplanar" objetos de dominio.

 

Yo necesitaría un par de buenas sesiones para que alguien me
convenciera (con código en la mano) de que usar los objetos del
dominio en la UI es más mantenible que usar DTOs y tenerlo todo bien
desacoplado.

Si necesitas tener todo bien desacoplado, entonces DTOs es necesario. Mi punto es que no siempre, en mi experiencia, es necesario llegar a tal nivel de desacoplamiento.

 

> Te dieron opciones para el tema del capitulo?

No, de hecho el libro es sobre TDD, pero el autor (cuidado, anda por
aquí, je, je) me ha pedido un capitulillo introductorio a DDD porque
pretende incluir capítulos similares de otros temas no necesariamente
relacionados. Yo había pensado el siguiente esquema:

1) Intro histórica, el libro de Evans y poco más
2) Conceptos básicos: lenguaje unificado, dominio, entidad, servicio,
repositorio, capa anticorrupción...
3) ¿Por qué con DDD podemos construir mejores sistemas? Respuesta:
porque son más fáciles de comprobar. Aquí podría hablar de la
"ignorancia de la persistencia" en los repositorios y la relación con
la inyección de dependencias.

Y con esto creo que sería más que suficiente para un capitulillo
introductorio a DDD. ¿No les parece?

Creo que con el punto 3 tenes suficiente para un capitulo, sin embargo, puede ayudar un poco de contexto si es que el prototipo de lector del libro pueda desconocer estos temas.

Un abrazo

----------------------------------
Carlos Peix

[Carlos Ble]

A mi me parece perfecto ;-)
Suena muy bien!


On 28 sep, 13:31, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> 2009/9/28 Carlos Peix <carlos.p...@gmail.com>:

> > 2009/9/28 José Manuel Beas <jose.m.b...@gmail.com>

>
> >> Sí, claro, los "javeros" tenemos más o menos el mismo problema con los
> >> patrones J2EE.
>
> >> Yo personalmente veo muy atractiva la arquitectura que proponen Greg
> >> Young o Udi Dahan para implementar "DDD en el mundo real" (esto lo
> >> digo yo). La separación entre consultas y comandos (CQS) y separar
> >> ambos lados con un anticorruption layer hace que todo sea mucho más
> >> sencillo y eficiente.
>
> >> Para mi, todo gira, conceptualmente hablando, en torno a la idea de
> >> que diseñamos a partir del dominio en vez de en torno a los datos. En
> >> este sentido, tengo un poco de reparo al ver todos aquellos sistemas
> >> que se están construyendo con el patrón Active Record, que es muy
> >> "database o datamodel centric".
>
> >> Pero claro, es necesario, para quitarle ese "halo" tener quizás una
> >> arquitectura "de todos los días" de referencia.
>
> >> Un saludo,
> >> Jose Manuel Beas
>
> >>http://www.agile-spain.com
> >>http://jmbeas.blogspot.com
>

> >> 2009/9/28 Carlos Peix <carlos.p...@gmail.com>:

> >> > 2009/9/28 jmbeas <jose.m.b...@gmail.com>