Dudas DDD

[Fabian Figueredo]

Aprovechando la excelente charla de hoy de Ángel Java Lopez, quiero
hacerles unas preguntas sobre DDD.

Reconozco que sigo muy apegado a la arquitectura tradicional de 3
capas, siempre cuando veo DDD me pregunto: ¿dónde va la lógica del
negocio?, ¿donde la persistencia? Sigo perdido…

Espero que ustedes puedan sacarme de esta ignorancia.

1 – Lógica del Negocio: No tengo en claro todavía donde va la lógica
del negocio concretamente ¿En el modelo? ¿En la capa servicios? ¿En
las dos partes?

2 – Repositorios y Servicios: No sé porque, pero no me gusta llamar a
Repositorios desde Controladores. ¿Está mal llamar a Repositorios
desde Servicios y utilizar estos servicios en los controladores, en
vez de usar Repositorios?

3 – Servicios que procesan IQueryable: En la charla, Ángel y Fabio
tocaron este tema. Lo que intento saber es si lo que yo realizo está
bien. Mis repositorios tienen pocos métodos *4 o 5* y algunos retornan
IQueryable, luego en la capa servicios es donde están los demás
métodos necesarios, donde realizo los procesos Linq.

4 – Validación de objetos: ¿Los objetos deben ser validados en la capa
servicios o en el modelo? Si fuera en el modelo., No llenaríamos las
clases con atributos? ¿Y qué hay con validaciones UI? ¿Son
infraestructura?

Bueno chicos, solo pondré 4 preguntas pero la lista podría llegar a
100. Gracias de antemano y espero sus respuestas.

Fabián Figueredo

[Snahider]

1 - Un servicio es el objeto que se encarga de coordinar las
operaciones de uno o más objetos, por lo tanto en DDD podemos
encontrar servicios en el dominio (domain model), infraestructura y
tambien lo son los application services.

Como el dominio(entities, value objets, domain services) es la
representación del negocio, la lógica referente al negocio debe estar
en el dominio. La decisión de donde ponerlo depende mucho de la regla
de negocio en sí; podría ser que tengas un comportamiento orden.Ordenar
() que realizé ciertos cambios en el estado de la orden y tu regla de
negocio podría estar ahi, o también tu regla podría ser que el cliente
no supere su límite de crédito, por lo tanto la regla podría ponerse
dentro de un servicio de dominio, un patrón muy usado para este caso
es el specification pattern, aunque también puede usarse dentro de una
entidad.

Algunos links sobre servicios:
http://jonathan-oliver.blogspot.com/2008/12/services-infrastructure-application.html
http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/08/21/services-in-domain-driven-design.aspx

Specification Pattern en DDD
http://sbtourist.blogspot.com/2006/01/case-for-specifications.html
http://sbtourist.blogspot.com/2006/02/another-case-for-specifications.html

2 - En Muchos ejemplos que usan (o dicen usar) DDD vas a ver que ponen
directamente el repositorio dentro del controlador, en estos casos la
lógica del negocio pasa a estar dentro de las entidades ya que no hay
nada que coordine esto. En ciertos casos, podría ser que esto se
mantenga dentro los conceptos de DDD, pero por lo general se termina
poniendo mucho del negocio dentro del controllador y también el
controllador empieza a crecer demasiado (Fat Controller). En lo
personal prefiero mantener los repositorios dentro de un servicio y
los servicios dentro de los controladores.

3 - En lo personal tengo muchas opiniones encontradas, ya que ahora
Linq pertenece a las librerias nativas de la framework y deberíamos
aprovechar sus capacidades. Pero también su uso abusivo puede causar
que muchas de las optimizaciones de los repositorios, no se tengan que
hacer en su implementacion misma sino en cualquier otra parte donde se
encuentren las llamadas Linq.

Linq y Repositories
http://mikehadlow.blogspot.com/2009/01/eric-evans-on-repositories.html
http://mikehadlow.blogspot.com/2008/03/using-irepository-pattern-with-linq-to.html
http://mikehadlow.blogspot.com/2009/01/in-search-of-wild-repository.html

4 - Las validaciones se deben encontrar sí o sí en el dominio, pero
esto no significa que no tengas otros lugares donde refuerces estas
validaciones, ejm:UI. Ahora, si las validaciones van en las entidades
o en los servicios de dominio, creo que no es un problema directamente
relacionado con DDD aunque existe mucha discusión sobre el tema. Yo
suelo poner las validaciones del negocio dentro del servicio y las
validaciones de ingreso de datos como atributos dentro de la entidad.

http://colinjack.blogspot.com/2008/03/domain-model-validation.html
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx
http://devlicio.us/blogs/billy_mccafferty/archive/2009/02/17/a-response-to-validation-in-a-ddd-world.aspx

Espero les haya servido de algo.
Muchos Saludos.
Angel Nuñez Salazar.

[Pedro Wood]

Hola Fabián, no soy un experto en el tema simplemente leí el libro, me gustó y lo aplico en mis proyectos desde entonces.

Va intercalado:

2009/12/19 Fabian Figueredo <fabianf...@gmail.com>

1 – Lógica del Negocio: No tengo en claro todavía donde va la lógica
del negocio concretamente  ¿En el modelo? ¿En la capa servicios? ¿En
las dos partes?

En la capa de dominio. Esta es la capa más importante para DDD y no debería tener dependencias a otras capas. Evan habla de 3 tipos de objetos: Entidad, Value Objects y Servicios. Pero no hay una separación entre entidades con datos por un lado y servicios con comportamiento por el otro. Sino que la lógica de negocio estará repartida en las entidades, los value objects y los servicios según su responsabilidad.

Ojo tener en cuenta que puede haber servicios en otras capas (la diferencia es que los servicios de esta capa se ocupan de la lógica de negocio mientras que los de otras capas no).

 

2 – Repositorios y Servicios: No sé porque, pero no me gusta llamar a
Repositorios desde Controladores.  ¿Está mal llamar a Repositorios
desde Servicios y utilizar estos servicios en los controladores, en
vez de usar Repositorios?

El Repositorio es parte del Dominio pero su implementación está en la capa de Infraestructura. O sea que no hay problema en llamar a repositorios desde el dominio, pero tampoco lo hay si lo querés llamar desde tu capa de aplicación.

 

3 – Servicios que procesan IQueryable: En la charla, Ángel y Fabio
tocaron este tema. Lo que intento saber es si lo que yo realizo está
bien. Mis repositorios tienen pocos métodos *4 o 5* y algunos retornan
IQueryable, luego en la capa servicios es donde están los demás
métodos necesarios, donde realizo los procesos Linq.

Esto ya va más allá de DDD que no se mete con estos detalles de implementación.

Hay 2 corrientes principales los que implementan una sola interfaz genérica para todos los repositorios y otros que implementan varias ej: IRepositorioCliente, IRepositorioPedido, y esos tienen métodos específicos tipo obtenerPedidosPorCliente.

 

4 – Validación de objetos: ¿Los objetos deben ser validados en la capa
servicios o en el modelo? Si fuera en el modelo., No llenaríamos las
clases con atributos? ¿Y qué hay con validaciones UI? ¿Son
infraestructura?

Las validaciones son en general lógica de negocio, salvo claro que estemos hablando del formato de la fecha o algo por el estilo que son validaciones de UI, que son parte de la capa UI.

Por qué decís que llenaríamos la clases con atributos ?

La idea es que un objeto esté siempre en un estado consistente y por ello la validación del objeto debería estar en su construcción. Para eso están las Factories.

Espero te sirva.

Saludos,

Pedro Wood

 

[Pedro Wood]

Perdón, quedó muy repetitivo mi email pero sólo vi el email de Angel después de apretar Send.

Saludos

2009/12/19 Pedro Wood <pedro...@gmail.com>

[José F. Romaniello]

El 19 de diciembre de 2009 19:06, Fabian Figueredo <fabianf...@gmail.com> escribió:

Aprovechando la excelente charla de hoy de Ángel Java Lopez, quiero
hacerles unas preguntas sobre DDD.

Reconozco que sigo muy apegado a la arquitectura tradicional de 3
capas, siempre cuando veo DDD me pregunto: ¿dónde va la lógica del
negocio?,  ¿donde la persistencia? Sigo perdido…

Espero que ustedes puedan sacarme de esta ignorancia.

1 – Lógica del Negocio: No tengo en claro todavía donde va la lógica
del negocio concretamente  ¿En el modelo? ¿En la capa servicios? ¿En
las dos partes?

Por todos lados, una entidad puede y debe tener cierta lógica que le corresponda a ella, y un servicio también. una arquitectura donde toda la lógica esta en los servicios y en las entidades de dominio solo hay datos pero no lógica, es un modelo anímico según Fowler y no va muy bien con DDD. http://martinfowler.com/bliki/AnemicDomainModel.html

 

2 – Repositorios y Servicios: No sé porque, pero no me gusta llamar a
Repositorios desde Controladores.  ¿Está mal llamar a Repositorios
desde Servicios y utilizar estos servicios en los controladores, en
vez de usar Repositorios?

IMHO Esta perfecto para mi, ese tipo de  servicio según vi hoy en NDDD se llama Application Service, pero alguien puede corregirme. En unhaddins para Conversation-per-BusinessTransaction, Fabio los llamo models, y en mi ejemplo de Chinook Media Manager, los llame Models como Fabio. Pero creo que la idea es básicamente esa. 

 

3 – Servicios que procesan IQueryable: En la charla, Ángel y Fabio
tocaron este tema. Lo que intento saber es si lo que yo realizo está
bien. Mis repositorios tienen pocos métodos *4 o 5* y algunos retornan
IQueryable, luego en la capa servicios es donde están los demás
métodos necesarios, donde realizo los procesos Linq.

Creo que esta bien, aunque en realidad un verdadero repositorio que aprovecha linq, debería implementar directamente IQueryable:

Interface: http://digg.com/u1C649

Implementación Nhibernate: http://digg.com/u1IJ9O

El repositorio en si ya es una colection, como hablamos con Fabio hoy no tiene metodo GetAll.  Si vos enumeras el repositorio ya tenes todos los items. (mmmm)

 

4 – Validación de objetos: ¿Los objetos deben ser validados en la capa
servicios o en el modelo? Si fuera en el modelo., No llenaríamos las
clases con atributos? ¿Y qué hay con validaciones UI? ¿Son
infraestructura?

Validation es un cross-cutting concern.http://en.wikipedia.org/wiki/Cross-cutting_concern 

Ocurre validación en la UI (mediante databinding), en la capa de servicios, en la base de datos mediante una constraint etc.

En donde se definen las reglas, cada uno lo hace diferente aunque yo vengo usando desde hace un tiempo la forma fluent de nhibernate validator, Fabio tiene muy buenos posts en su blog, busca el tag validator.

Personalmente, y de acuerdo con lo que he hablado con Gustavo y Fabio, llenar de atributos las clases no es muy cool, sobre todo por que pega el dominio a una arquitectura de validación especifica.

 

Bueno chicos, solo pondré 4 preguntas pero la lista podría llegar a
100. Gracias de antemano y espero sus respuestas.

Fabián Figueredo

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

[Fabian Figueredo]

Muchas gracias Snahider, Pedro y José.
En líneas generales y luego de leer detenidamente sus respuestas,
concluyo que la forma en que aplico DDD en mi proyecto es correcta.

Contestando la pregunta de Pedro sobre los atributos. Yo utilizo
NHValidator para validar las entidades, por eso ese lado va mi
pregunta.

Se que existen varios métodos para validar entidades sin utilizar
atributos, el bueno de Mario Chávez me comentó de la existencia de
Fluent NHValidator.

Bueno, otra vez, muchas gracias por su tiempo. Un abrazo y que pasen
muy bien las fiestas.

Fabián Figueredo

On 20 dic, 02:53, José F. Romaniello <jfromanie...@gmail.com> wrote:
> El 19 de diciembre de 2009 19:06, Fabian Figueredo <

> fabianfiguer...@gmail.com> escribió:

>
> > Aprovechando la excelente charla de hoy de Ángel Java Lopez, quiero
> > hacerles unas preguntas sobre DDD.
>
> > Reconozco que sigo muy apegado a la arquitectura tradicional de 3
> > capas, siempre cuando veo DDD me pregunto: ¿dónde va la lógica del
> > negocio?,  ¿donde la persistencia? Sigo perdido…
>
> > Espero que ustedes puedan sacarme de esta ignorancia.
>
> > 1 – Lógica del Negocio: No tengo en claro todavía donde va la lógica
> > del negocio concretamente  ¿En el modelo? ¿En la capa servicios? ¿En
> > las dos partes?
>
> Por todos lados, una entidad puede y debe tener cierta lógica que le
> corresponda a ella, y un servicio también. una arquitectura donde toda la
> lógica esta en los servicios y en las entidades de dominio solo hay datos

> pero no lógica, es un modelo anímico según Fowler y no va muy bien con DDD.http://martinfowler.com/bliki/AnemicDomainModel.html

> > altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

[Gustavo Ringel]

Hi, sólo por poner una piedrita como siempre, el uso de repositorios, servicios, etc, debieran ser algo superfluo en lo que es DDD.

Es cierto que el resultado de un proceso de DDD debe ser una aplicación orientada a objetos que siga patrones reconocibles de diseño y que se adapte a la realidad que se esta modelando, pero en términos prácticos viendo el resultado final no debiera haber forma de diferenciar código que se escribió usando DDD o no. La base de DDD es la creación de un lenguaje ubicuo, la participación de los expertos del dominio durante todo el proceso, etc.

En mi caso no he tenido proyectos en los que pueda aplicar DDD, pero si he tenido proyectos en los que el resultado final sigue algunas de las prácticas recomendadas en el libro de DDD.

Según lo que yo entiendo, si hay una desconexión entre los objetos de la aplicación y la realidad, por haber desconectado al cliente/experto durante el desarrollo, entonces toda buena práctica que se use es inútil y no se hizo un proceso DDD

Gustavo.

2009/12/20 Fabian Figueredo <fabianf...@gmail.com>

[Codesol - Alberto Arroyo]

Hola

 

Lamentablemente me perdí la VAN, espero el video con ansias:

 

Es cierto que el resultado de un proceso de DDD debe ser una aplicación orientada a objetos que siga patrones reconocibles de diseño y que se adapte a la realidad que se esta modelando, pero en términos prácticos viendo el resultado final no debiera haber forma de diferenciar código que se escribió usando DDD o no. La base de DDD es la creación de un lenguaje ubicuo, la participación de los expertos del dominio durante todo el proceso, etc.

 

Exacto: La base de DDD es la creación de un lenguaje ubicuo, un conjunto de estereotipos…

 

Como saben sigo  usando CSLA .NET en algunos proyectos, y me permite eso, integrar equipos a través de un lenguaje común.

 

Suena a broma, pero da mucha risa ver a los analistas de negocio (expertos de dominio) hablar en estereotipos con nosotros los del equipo de desarrollo.

 

Saludos….

Se certificó que el correo entrante no contiene virus.
Comprobada por AVG - www.avg.es
Versión: 9.0.717 / Base de datos de virus: 270.14.115/2577 - Fecha de la versión: 12/20/09 02:35:00

[Pedro Wood]

Hola

Coincido en que lo fundamental de DDD es el lenguaje ubicio. Lo dice Evans mismo en esta entrevista en infoQ: http://www.infoq.com/interviews/domain-driven-design-eric-evans

Según lo que yo entiendo, si hay una desconexión entre los objetos de la aplicación y la realidad, por haber desconectado al cliente/experto durante el desarrollo, entonces toda buena práctica que se use es inútil y no se hizo un proceso DDD

Estás diciendo que aplicar las buenas prácticas y patterns del libro es inútil ? Seguramente te referís a que si no hay lenguaje ubicuo no sería DDD, no ?

De todas formas no creo que sea tan blanco o negro. Quizás el experto en el dominio no es tan experto, quizás no lo tengo tan disponible como quisiera, quizás tengo intermediarios... pero puedo llegar a tener otros recursos como por ejemplo investigar los temas que necesite y ser mi propio experto.

Es un proceso continuo que siempre se puede seguir refinando con lo cual en distintos proyectos habré alcanzado distintos grados de refinación.

Saludos,

Pedro Wood

[Gustavo Ringel]

No, estoy diciendo que podes hacer un Helicoptero excelente cuando se necesitaba un Barco.

Gustavo.

2009/12/21 Pedro Wood <pedro...@gmail.com>

--

[Omar del Valle]

Hola,

 

Yo si pude estar en la excelente VAN de Angel.. y se formó un debate muy bueno al final de la misma respecto al uso de repositorios... en ese momento pregunté mi duda.. pero no estoy muy seguro de que me entendieran :( o de saber explicar exactamente a lo que me refería, así que la dejo igual por acá.

 

Hace unos días.. hemos tenido un debate sobre la construcción de los repositorios en DDD.. El tan odiado método GetAll... ;)

 

En DDD, sabemos que el dominio accede a los repositorios mediante la interfaz, esto hace que cada método que escribamos en el repositorio y que tenga algún significado para el dominio, debe estar en dicha interfaz. Por ejemplo, yo tengo un repositorio base del cual heredan cada uno de los repositorios que implemento. Este repositorio base tiene un método protegido de nombre GetAllBy, al cual le paso un predicado. Esto me permite reutilizar el mismo cuando tengo que seleccionar elementos filtrados por alguna característica.

 

Ahora bien, en mi caso ese método no es accesible desde el dominio (protegido) por lo que mis interfaces de los repositorios tendrán que exponer un método por cada característica que deseen filtrar.

 

EJ: PersonasMayores65(), PersonasConHijos(), etc..

 

Cada repositorio en estos métodos, usa el método base de GetAllBy pasando el predicado que corresponda. La ventaja que le veo a esto es que divido perfectamente la responsabilidad entre el dominio y los repositorios.. pero tiene la desventaja que podría terminar teniendo muchos métodos en la interfaz.

 

Lo que me comentaban, era exponer el GetAllBy al dominio, y que este pudiera pasar el predicado de la consulta que desea realizar. Ventajas, no necesito tantos métodos en las interfaces, desventaja, que la responsabilidad de la consulta ya no está solo en los repositorios.. y si ocurre un problema, puede estar en el dominio o en el repositorio.

 

¿Qué creen de estas dos variantes?

 

Salu2

Omar

[Carlos Peix]

Doy por sentado que todos estamos de acuerdo en que los repositorios, en general, se implementan en relacion 1 a 1 con los Aggregates (DDD) y que, tambien en general, se define la interfaz en el modelo y la implementacion en Infraestructura (o acceso a datos).

Lo que dice Evans y Fowler sobre los repositorios es que su protocolo (o interfaz publica) debe implementar una semantica de coleccion. En otras palabras, transmitir la idea de que detras de la interfaz hay una lista de elementos y que, mediante sus metodos, obtengo un subconjunto de esos elementos segun las necesidades.

En la implementacion hay dos vertientes, ninguna de las cuales ha sido desestimada por Evans o Fowler (aunque ambos han dado a conocer sus preferencias).

Una de ellas conduce a colocar un metodo distinto por cada necesidad (GetByName, GetByCategory, etc), todas retornando un subconjunto de elementos.

La segunda es establecer un unico metodo (ademas de GetById, probablemente) que reciba como parametro una especificacion de query y devuelva los elementos que se ajustan al criterio. Esta especificacion de query puede ser basada en un QueryObject diseñado especificamente, LINQ si el mecanismo subyacente de consulta lo soporta o hasta alguna implementacion especifica del ORM si estamos dispuestos a tolerar la referencia en nuestro modelo de dominio.

Ninguna de las dos contradice la semantica de coleccion, ya que, en mi opinion, implementar ICollection o IQueryable no es la unica manera, basta con que la implementacion sea "consistente" con la idea de coleccion de elementos. En algun debate, publico y privado

La primera de las opciones conduce, logicamente a protocolos mas grandes y hasta riesgo de duplicacion, aunque la implementacion de GetByCriteria protegido que menciona Omar controla ese detalle.

La segunda obliga a establecer un mecanismo de especificacion de consulta que, inevitablemente, se cuela en el modelo del dominio. Muchos argumentan que con la llegada de LINQ ya no tendriamos que agregar una dependencia externa. Otro riesgo, en mi opinion, es que la definicion de los queries estan distribuidos por el dominio en lugar de estar centralizados en la implementacion de los repositorios.

En cualquier caso, estoy seguro de que una implementacion u otra, no invalida el resto de los conceptos de DDD asi que pueden usar la que prefieran.

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

2009/12/21 Omar del Valle <omar...@gmail.com>

[Omar del Valle]

;-)

--

[Carlos Peix]

Hola Fabian,

En mi opinion, DDD es una "filosofia" con la cual se encara el diseño del "modelo de dominio".

Me todo unos renglones para reforzar el entendimiento de el concepto de "modelo de dominio". Usualmente cuando diseñamos software estamblecemos un "modelo" del "dominio" del problema en cuestion. Este modelo usualmente es una abstraccion util a los propositos del software que queremos construir.

Por ejemplo, en un sofware de agenda, es util diferenciar entre lineas telefonicas de Fax, Celular, Work o Home pero no el proveedor del servicio. El modelo solo llega hasta donde es necesario, por eso es modelo, es abstraccion.

La filosofia DDD sugiere poner enfasis en lograr una abstraccion que represente profundamente el dominio modelado, con el detalle necesario, no menos. Es aqui donde se propone captar el lenguaje y la semantica del dominio en un lenguaje ubicuo, en un modelo del dominio lo suficientemente rico.

Luego Evans avanza proponiendo algunos patrones y los describe en su libro.

1) En un modelo de 3 capas, el modelo del dominio definitivamente corresponde a la etapa de logica de negocios, protegida, eventualmente, por una fachada de servicios a la cual accede la capa de interfaz a usuario.

2) Si accedes directo al modelo desde los controllers, tomas el riesgo de que se te cuele logica del negocio en el controller y perdes la opcion de establecer "logica de aplicacion" que es lo que hacen usualmente las fachadas de servicio.

3) Supongo que quisiste decir "Repositorios que implementan IQueryable". En mi opinion no es la unica manera de implementarlos. En algun debate, publico y privado con Fabio (el tano) no acordamos en este punto :-)

4) Creo que hay varias capas de validacion y yo la implemento a distintos niveles. De todas maneras, es un tema que aun no tego cerrado :-)

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

2009/12/19 Fabian Figueredo <fabianf...@gmail.com>