¿Es compatible el uso de JPA con DDD?
José Manuel Beas
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
Carlos Peix
Aunque no conozco nada de JPA me animo a opinar basandome en lo que has escrito.
Yo diferencio dos tipos de dependencias: las que meramente violan el
purismo y las que generan problemas para llevar adelante otras
practicas DDD o agiles.
Entonces yo diria, ese atributo impide que realices unit testing?
impide la injeccion de otras implementaciones de repositorios? impide
que puedas testear el objeto si el entorno JPA?
Carlos Peix
2009/4/23 José Manuel Beas <jose....@gmail.com>:
Carlos Peix
carlo...@gmail.com
cel: 15-4406-7571
Hadi Hariri
Sent from my iPhone
On 23/04/2009, at 12:56, José Manuel Beas <jose....@gmail.com>
wrote:
José Manuel Beas
Hace unos meses escribí en mi blog [1] sobre esto usando un ejemplo.
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
Hadi Hariri
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,
Yo más que persistencia, hago las pruebas de mapeos, etc. pero desde luego ya confio en la herramienta que utilizo (que en mi caso es NHibernate/Hibernate). Que haga pruebas de algunos escenarios o consultas un poco más complejas, no lo niego, pero por lo general, lo que es probar la persistencia poco.
Ahora si, lo que si pruebo es todo lo que está por encima de la persistencia. Y si esta persistencia no lo puedo suplantar en mis pruebas, entonces eso me causa un problema.
ActiveRecord, desde luego, en mi opinión es como tu bien dices un modelo de trabajar más enfocado hacía data-driven-design, dado además la propia definición y creo que contradice DDD.
Ahora bien, si con JPA (que no lo conozco) tiene que haber un mapeo directo entre tablas de la base de datos y tus entidades, y no hay ignorancia de la persistencia, entonces si veo esto como un impedimiento a la hora de trabajar con DDD. Igual no es imposible, pero creo que puede suponer esfuerzos., más si como digo promueve ese "mapeo".
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
--
Blog: http://hadihariri.com
Twitter: http://twitter/hhariri
José Manuel Beas
Teóricamente, poner la anotación @Entity en un objeto no tiene más
impacto del "import" que hay que poner y algún detalle en el
despliegue. Las anotaciones sirven para informar al ORM (p.ej.
Hibernate) sobre el mapeo. Vienen a sustituir los xml de
configuración. Por tanto, si yo escribo mis entidades del dominio
"como Dios manda", pues no debería haber problema. Como reclamaba
Carlos, se pueden probar unitariamente sin problema alguno: no
requerirán de ningún colaborador fuera del dominio.
Ahora bien, DDD dice que los constructores los hacemos nosotros y que
los repositorios usan factorías para "rehidratar" los objetos que
viene de la BD. JPA me obliga a incluir un constructor sin parámetros
y los setters para "rehidratar" los objetos por su cuenta. No sé, me
parece que hay algo raro ahí. ¿Por qué tengo que añadir esto a mis
objetos simplemente porque mi ORM me obliga? ¿No os huele también a
vosotros un poco mal?
Pero claro, si en vez de usar JPA y sus cómodas anotaciones, me tengo
que currar todos los mapeos con código "ad hoc" en mis DAOs y lo más
probable es que introduzca errores en mi código. Eso es casi peor.
2009/4/23 Hadi Hariri <hadih...@gmail.com>:
Hadi Hariri
params y todos los métodos virtuales (aunaue en java eso da igual).
Ahora no tienes que decorar ni usar xml si no quieres. Pero irelevante
a esto está la cuestión del mapeo entre objetos y tablas. Eso no te
lo debe imponer.
Sobre si merece la pena , por supuesto. Más cuando algunas cosas
incluso no son malas prácticas del todo. Por lo menos desde mi punto
de vista.
On 23/04/2009, at 23:11, José Manuel Beas <jose....@gmail.com>
wrote:
>
Jose Raya
Respecto al tema del acoplamiento y las anotaciones, yo no le daría
importancia ya que se trata solamente de facilitar la configuración;
se podría hacer todo el mapeo por xml, mientras que los setters no son
obligatorios (puedes inyectar los valores directamente a los campos
privados) 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.
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. En mi
caso, al menos, hasta que no empecé a trabajar con ORM no me planteé
trabajar con un modelo del dominio debido al coste de tratar la
persistencia.
En cuanto a las pruebas unitarias, nosotros tampoco solemos hacer
pruebas del mapeo en sí, sino pruebas de la funcionalidad que,
normalmente, incluirán parte del mapeo ya que habrá que navegar por
asociaciones y leer los valores de los atributos.
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
entidades con métodos de negocio, atributos y asociaciones, no
tendremos herencia. De todos modos, por mi experiencia con Ruby On
Rails, no parece una mala solución (mucho mejor que otras cosas que he
hecho con Java y JDBC, por ejemplo, y mucho mejor que ADO.Net).
Saludos,
Jose.
Hadi Hariri
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
Hablando estrictamente en términos de DDD, donde estaría el repositorio? Y los agregados?
Manuel A. Rubio
creo que una solución al uso de ORM, sería el uso de base de datos de objetos,
en las que la persistencia es implícita y transparente al lenguaje. Está db4o
para Java, que está desarrollada por Indra y, según he podido ver, funciona
bastante bien... sobre su uso con respecto a DDD... primero tendría que
informarme mejor de los puntos claves y/o principales del mismo :-P ...
Un saludo.
Manuel A. Rubio "Bombadil"
Usuario de GNU/Linux #323628 acorde a http://counter.li.org/
GPG ID 1C84979D ftp://bosqueviejo.net/pub/bombadil.asc
Técnico en Admin. Sistemas Informáticos
José Manuel Beas
relación dices que tiene db4o con Indra?
2009/4/24 Manuel A. Rubio <bomb...@bosqueviejo.net>:
Hadi Hariri
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.
Manuel A. Rubio
me he equivocado, Indra no lo desarrolla... lo usa:
http://www.db4o.com/about/customers/success/indra.aspx
Un saludo.
Manuel A. Rubio
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.
José Manuel Beas
> Hola,
>
> 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...
>
Voy a traducir la definición que da Martin Fowler en su libro PoEAA
[1] de "Active Record":
"Un objeto que envuelve un fila en una tabla o vista de BD, encapsula
el acceso a la BD y añade lógica de dominio sobre esos datos".
Dicho esto, estamos asumiendo que este patrón es aplicable sólo cuando
tu aplicación es un CRUD o al menos cuando tu modelo de dominio es
casi 1:1 con tu BD.
> ¿por qué se contradice con DDD?
>
"ActiveRecord seems to defeat the entire concept of DDD, ActiveRecord
promotes a database centric model"
Claro, me puedes decir que si creas el modelo de dominio como más te
guste y luego haces que tu modelo de datos se ajuste a que cada objeto
es una tabla y cada instancia una fila... pero no parece que eso pueda
mantenerse fácilmente...
[1] http://martinfowler.com/eaaCatalog/activeRecord.html
[2] http://geekswithblogs.net/gyoung/archive/2006/05/03/77171.aspx
Hadi Hariri
modelo de datos.
Sent from my iPhone
On 24/04/2009, at 18:09, José Manuel Beas <jose....@gmail.com>
wrote:
>
Carlos Peix
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
pedro wood
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 otro lado cuales son nuestras opciones para hacer DDD o Domain
Model:
- ORM
- Hacer los data mappers a mano
- Base de datos de objetos
- ?
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.
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.
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 ?
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.)
Saludos,
Pedro
José Manuel Beas
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
Hadi Hariri
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.
Independientemente de si poner @Entity o no tiene efecto sobre DDD, si tiene una implicación de tener una depedencia directa sobre una libreria, cosa que por ejemplo usar un constructor protegido no lo 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.
Ahí estoy de acuerdo, igual que declarar todos los métodos virtuales.
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.
Pero AR no es compatible con DDD porque AR implica necesariamente un modelo dirigido por datos, no por dominio, con lo cual como tiene sentido?
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.
Entonces no estás usando el patrón AR verdad?
Pedro Wood
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
En el libro de DDD se indica que uses el mismo modelo de datos que el del código, para mantener todo bajo el mismo lenguaje ubicuo y no introducir ambigüedades ni conceptos nuevos.
O sea que, modificar tu modelo de datos para que coincida con tu modelo de código (basado en el lenguaje ubicuo) va a ser algo que DDD busca conseguir.
Por supuesto que al revés no.
pensar que las aplicaciones donde se puede aplicar esto son muy
"CRUDish". No digo que no tengan aplicación práctica, al contrario,
Que el modelo de dominio coincida con el modelo de datos no implica CRUD.
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").
Si, ojo, yo dije que Active Record no implica ni data-driven ni CRUD, no que fuera ignorante 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".
Le consigo trabajo en otra empresa !!! ;-D
No, volviendo a la seriedad, no usaría Active Record para todos los casos, si no puedo controlar el modelo de datos entonces no lo usaría.
Sólo he utilizado Active Record en unos pocos casos, salvo estos uso Domain Model + ORM.
Pedro
Pedro Wood
2009/4/26 Hadi Hariri <hadih...@gmail.com>
Hola.
Por qué poner @Entity implica una dependencia con la persistencia ?
> Pero AR no es compatible con DDD porque AR implica necesariamente un modelo dirigido por datos, no por dominio, con lo cual como tiene sentido?
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.
Quizás la implementación que hace RoR no sea un Active Record puro y tal como lo describe Fowler sino algo más potente.
Saludos,
Pedro
Hadi Hariri
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.
Es cierto, no necesita que exista una base de datos, pero está intrínsicamente ligado hacía el concepto de tabla de una base de datos relacional, y el registro actual (active record).
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.
Ok, pero dejando a un lado los objetos anemicos, que nadie dice que AR tenga que serlo, como modelas conceptos como agregados?
-~----------~----~----~----~------~----~------~--~---
Pedro Wood
> Ok, pero dejando a un lado los objetos anemicos, que nadie dice que AR tenga que serlo, como modelas conceptos como agregados?
Por eso lo que plantee era que AR no era data-driven ni limitado a CRUD, no que fuera DDD o no lo fuera.
Como toda elección tiene sus ventajas y desventajas. Y funciona bien en ciertos escenarios y en otros no (lo mismo que DDD es más adecuado para ciertos escenarios que para otros).
Saludos,
Pedro
Hadi Hariri
Jose Raya
Tal y como yo lo veo, el problema de AR para hacer DDD es que AR impone un mapping excesivamente simple (básicamente 1 a 1), por lo que, si tenemos un dominio complejo no nos servirá para hacer DDD (hasta ahí, de acuerdo con Hadi). De todos modos, eso no quita que, en dominios relativamente simples, no te pueda servir (a eso me refería con lo del DDD "descafeinado"). Estoy con Pedro en que AR no es data-driven ni limitado a CRUD ya que puedes tener lógica de dominio arbitrariamente compleja en las clases del AR (por ejemplo, en las aplicaciones RoR suele ser el caso).
Probablemente, mi problema con esta cuestión se deba a que, en cierta manera, asimilo (por no decir confundo) el hecho de tener un Domain Model con hacer DDD, cosa que, en realidad, no es cierta. Para los que conocéis mejor la metodología DDD, ¿qué otras ventajas aportaria aparte de las propias ventajas de tener un Domain Model?
Saludos,
Jose
Diego Fontdevila
Saludos,
Diego
--
Diego
Pedro Wood
Sin embargo, hay una entrevista a Eric Evans en infoq [1] en donde le preguntan cual sería el mínimo conjunto de prácticas de DDD y lo que contesta es que lo fundamental es el lenguaje único y después menciona los bounded contexts y que a su criterio un equipo que haga sólo esas 2 cosas ya está haciendo DDD.
Saludos,
Pedro
[1] http://www.infoq.com/interviews/domain-driven-design-eric-evans (en particular la 3ra pregunta que pueden ver abajo sin necesidad de mirar el video)
Hadi Hariri
Tampoco he escuchado esa entrevista y desconozco si literalmente Evans dice que solo con esos dos es suficiente, pero desde luego creo que en la práctica sería difícil hacerlo.
José Manuel Beas
Lo digo con todo el cariño, eh. Que no se mosquee nadie conmigo, por favor. :-)
Por entrar a lo del conjunto mínimo de prácticas para hablar de DDD, no seré yo quien corrija a Eric Evans, pero creo que hablar de DDD sin hablar de "persistence ignorance" y de "aggregate roots" (a mi) se me queda un poco corto. Por supuesto que el lenguaje único y los contextos separados son lo más importante, pero a la hora de implementarlo con un diseño altamente acoplado (p.ej. porque nuestros contextos separados están acoplados con relaciones entre tablas de un único modelo de datos compartido) pues estaríamos haciendo un flaco favor.
Ojo, no estoy hablando de AR en este caso (tampoco de JPA ni de ningún ORM). Por eso, quizás estamos ya un poco off-topic...