Comienzo disparando bajo, para que haga daño. :-)
Supongo que la mayoría de vosotros tendrá más o menos claro el
concepto del Repositorio y las Entidades. (Si no, podemos entrar a
discutir eso antes).
Partiendo del principio de que el dominio (incluidas Entidades, VOs,
Servicios de Dominio y Repositorios) son agnósticos de la
persistencia, ¿cómo encaja JPA en todo esto?
Yo, personalmente, tengo la sensación de que poner @Entity en una
Entidad me está introduciendo una dependencia:
a) innecesaria
b) indeseable
Innecesaria porque todos los aspectos de la persistencia se resuelven
en la implementación particular que hagamos del Repositorio.
Indeseable porque introduce un acoplamiento con el modelo de datos que
debería quedar limitado al Repositorio.
Ahora bien, "algo me dice" que estoy equivocado, pero no consigo ver dónde.
Un saludo,
JMB
Un saludo,
Jose Manuel Beas
Usar las anotaciones de JPA implica un acoplamiento "estático", es
decir, en tiempo de compilación.
En cuanto a las pruebas unitarias, depende de cómo te las plantees.
Hay gente que se empeña en "probar la persistencia". Yo creo que eso,
en DDD significa probar la implementación de los repositorios, lo cuál
puede llevarnos a probar DAOs y factorías, pero no la lógica de
negocio que debería haber en las entidades. (Yo me he encontrado
discutiendo sobre esto con gente que sigue pensando en "modelos
anémicos" mientras dice que hace DDD).
@Hadi
Creo que estoy equivocado porque, cuando el modelo de dominio es
idéntico al modelo de datos, hay un "tufillo" a "trabajo que me podría
ahorrar"... No sé, quizás sería compatible con un enfoque
"ActiveRecord" o algo así... pero ahí me encuentro incómodo, porque
creo que ActiveRecord es un patrón que me enfoca hacia un modelo
"data-driven" en vez de uno "behaviour-driven". No soy capaz de decir
por qué creo que estoy equivocado, sólo es una "sensación rara".
[1] http://jmbeas.blogspot.com/2008/07/spring-jpa-y-dbunit-2.html
Un saludo,
JMB
En cuanto a las pruebas unitarias, depende de cómo te las plantees.
Hay gente que se empeña en "probar la persistencia". Yo creo que eso,
en DDD significa probar la implementación de los repositorios, lo cuál
puede llevarnos a probar DAOs y factorías, pero no la lógica de
negocio que debería haber en las entidades. (Yo me he encontrado
discutiendo sobre esto con gente que sigue pensando en "modelos
anémicos" mientras dice que hace DDD).
@Hadi
Creo que estoy equivocado porque, cuando el modelo de dominio es
idéntico al modelo de datos, hay un "tufillo" a "trabajo que me podría
ahorrar"... No sé, quizás sería compatible con un enfoque
"ActiveRecord" o algo así... pero ahí me encuentro incómodo, porque
creo que ActiveRecord es un patrón que me enfoca hacia un modelo
"data-driven" en vez de uno "behaviour-driven". No soy capaz de decir
por qué creo que estoy equivocado, sólo es una "sensación rara".
[1] http://jmbeas.blogspot.com/2008/07/spring-jpa-y-dbunit-2.html
Un saludo,
JMB
Finalmente, yo diría que Active Record más que contradecir DDD lo que
hace es dar una versión "descafeinada" ya que, aunque podremos tener
El Friday 24 April 2009 15:59:05 escribió:
> ActiveRecord no tiene sentido porque la propia definición del patrón
> implica un modelado guiado por una base de datos existente, que es
> completamente contrario a DDD.
sino me equivoco, el diseño de base de datos, en sí, está indicado y
desarrollado para ser empleado por usuarios no informáticos, es decir, que el
cliente mismo, podría definir su negocio en lógica de tipo base de datos,
usando un lenguaje de 4ª generación como SQL o QBE para realizar el
tratamiento de datos y las consultas y, teniendo en cuenta que el modelo de
dominio habla en los términos que el cliente usa para definir sus campos...
¿por qué se contradice con DDD?
Un saludo.
2009/4/24 Jose Raya <jose...@gmail.com>:
>
> ... por lo que, al final, el único requisito que te impone JPA
> es el tener un constructor sin parámetros. Estoy de acuerdo en que no
> es lo ideal desde el punto de vista DDD pero tampoco me parece un
> precio excesivamente alto a pagar a cambio de no tener que preocuparte
> de la persistencia.
En mi opinion el constructor sin parametros no molesta para nada a
DDD, yo los creo protected y no son accesibles desde fuera de la
clase. El unico problema que considero el extremo del purismo es que
"esta ahi solo para el ORM".
> No sé si en el apartado de recursos hay alguien que haya tratado el
> tema de DDD + ORM pero creo que parte del problema es que, cuando
> Evans escribió el libro sobre DDD, las herramientas de ORM no estaban
> tan extendidas como ahora ya que yo lo veo como muy relacionado.
Respecto de los ORMs y DDD, creo que si existian y muy buenos en la
epoca del libro, se me ocurre TopLink por ejemplo.
DDD no se mete con la persistenica, solo habla de los repositorios y
deja libertad sobre su implementacion.
> En mi caso, hasta que no empecé a trabajar con ORM no me planteé
> trabajar con un modelo del dominio debido al coste de tratar la
> persistencia.
Definitivamente mucha gente que practica DDD, utiliza ORMs
Carlos Peix
Te contesto por ahí dentro...
2009/4/26 pedro wood <pedro...@gmail.com>:
>
> Hola.
> Por qué poner @Entity implica una dependencia con la persistencia ?
> Si nos olvidamos por un momento de que eso lo utiliza JPA para la
> persistencia y lo pensamos de esta forma: los distintos elementos del
> *domino* son *Entidades*, Value Objects, Servicios, etc., entonces al
> aclarar que un objeto del domino es de tipo Entidad no me lo relaciona
> con la persistencia, sino que me lo relaciona con un determinado tipo
> de objeto del dominio.
>
Sí, yo opino igual, aunque hay que reconocer que (siendo puristas)
estamos escribiendo código (el constructor y los get/setters) sólo
para que el ORM pueda usarlos.
>
> Por otro lado cuales son nuestras opciones para hacer DDD o Domain
> Model:
> - ORM
> - Hacer los data mappers a mano
> - Base de datos de objetos
> - ?
>
Aclaración: ¿Los data mappers para ti pueden ser DAOs extendiendo de
un DAO genérico?
> De los cuales hacer los mappers a mano (o incluso generarlos) implica
> después un costo alto en mantenibilidad.
> Base de datos de objetos no opino porque nunca lo hice.
>
Hay abierto un hilo sobre "db4o" a ver si alguien se atreve a mostrar
un ejemplo y vemos qué pros/cons tiene.
> Por eso coincido en que un constructor protected sin parámetros es un
> precio muuy bajo que pagar a cambio de las ventajas del ORM.
>
Estoy de acuerdo.
> Pienso que DDD se lleva mejor con Domain Model + ORM / data mappers
> que con Active Record, pero Active Record no significa data-driven ni
> CRUD para nada.
> Salvo que tenga un modelo de datos preexistente puedo crear mi dominio
> como me parezca (léase guiado por el comportamiento y no por los
> datos) y después hacer que la base de datos se ajuste al mismo.
No estoy de acuerdo. Active Record es un patrón que se basa en que
nuestro modelo de dominio *coincide* con nuestro modelo de datos. Es
decir, si necesitas modificar el modelo de dominio, tendrás que
modificar el modelo de datos, y *viceversa*. A mi eso me lleva a
pensar que las aplicaciones donde se puede aplicar esto son muy
"CRUDish". No digo que no tengan aplicación práctica, al contrario,
pero que eso no va en el sentido que propugna DDD, donde el modelo de
dominio no se ve afectado de ninguna manera por restricciones que
podamos tener en nuestro modelo de datos (es la "ignorancia de la
persistencia").
> Incluso con Active Record todavía puedo poner el foco en el dominio,
> usar el lenguaje ubicuo, bounded contexts, entidades, value objects,
> etc., etc.
>
Al principio sí, pero qué pasa cuando el DBA te dice: "lo siento, pero
esta tabla tienes que desnormalizarla porque si no, esto no tira".
> Quizás una discusión interesante sería cuales son las cosas más
> importantes en DDD, el foco en el dominio, el lenguaje ubicuo o los
> repositorios, entidades y servicios ?
Abre un hilo nuevo para esto, por favor, que si no nos liamos...
> Creo que estas cosas tienen distinto peso.
> Para poner un ejemplo el repositorio es un patrón que me ayuda a no
> meter la persistencia en la lógica del dominio. Pero, es la única
> forma de lograrlo ?
>
> Después de todo mi objetivo no es hacer DDD por hacer DDD sino porque
> me ayuda a hacer un mejor software (que maneje bien las complejidades
> del dominio, sea flexible, mantenible, etc., etc., etc.)
>
+1
> Saludos,
>
> Pedro
Hola.
Por qué poner @Entity implica una dependencia con la persistencia ?
Si nos olvidamos por un momento de que eso lo utiliza JPA para la
persistencia y lo pensamos de esta forma: los distintos elementos del
*domino* son *Entidades*, Value Objects, Servicios, etc., entonces al
aclarar que un objeto del domino es de tipo Entidad no me lo relaciona
con la persistencia, sino que me lo relaciona con un determinado tipo
de objeto del dominio.
Por eso coincido en que un constructor protected sin parámetros es un
precio muuy bajo que pagar a cambio de las ventajas del ORM.
Pienso que DDD se lleva mejor con Domain Model + ORM / data mappers
que con Active Record, pero Active Record no significa data-driven ni
CRUD para nada.
Salvo que tenga un modelo de datos preexistente puedo crear mi dominio
como me parezca (léase guiado por el comportamiento y no por los
datos) y después hacer que la base de datos se ajuste al mismo.
Incluso con Active Record todavía puedo poner el foco en el dominio,
usar el lenguaje ubicuo, bounded contexts, entidades, value objects,
etc., etc.
Sí, yo opino igual, aunque hay que reconocer que (siendo puristas)
estamos escribiendo código (el constructor y los get/setters) sólo
para que el ORM pueda usarlos.
Aclaración: ¿Los data mappers para ti pueden ser DAOs extendiendo de
un DAO genérico?
No estoy de acuerdo. Active Record es un patrón que se basa en que
nuestro modelo de dominio *coincide* con nuestro modelo de datos. Es
decir, si necesitas modificar el modelo de dominio, tendrás que
modificar el modelo de datos, y *viceversa*. A mi eso me lleva a
pensar que las aplicaciones donde se puede aplicar esto son muy
"CRUDish". No digo que no tengan aplicación práctica, al contrario,
pero que eso no va en el sentido que propugna DDD, donde el modelo de
dominio no se ve afectado de ninguna manera por restricciones que
podamos tener en nuestro modelo de datos (es la "ignorancia de la
persistencia").
Al principio sí, pero qué pasa cuando el DBA te dice: "lo siento, pero
> Incluso con Active Record todavía puedo poner el foco en el dominio,
> usar el lenguaje ubicuo, bounded contexts, entidades, value objects,
> etc., etc.
>
esta tabla tienes que desnormalizarla porque si no, esto no tira".
No coincido con tu punto de vista.
Para AR no se necesita tener un modelo de datos preexistente y en mi opinión no implica si o sí hacer data-driven, y sí es compatible con behaviour-driven.
Quizás mi visión es diferente porque está influenciada por la implementación que hace Ruby On Rails (RoR) de Active Record, con RoR se puede modelar pensando en el comportamiento, los roles y las responsabilidades tranquilamente, nada me impide tener una lógica rica como la tengo con Domain Model.
-~----------~----~----~----~------~----~------~--~---