¿Qué problemas encuentra con esta vista en el diseño impulsado por dominio?

Question

Acabo de escribir una larga (y desordenada) blogpost sobre mi opinión sobre el diseño impulsado por dominio en la actualidad, con frameworks como spring e hibernate masivamente en uso.

Le pediría que detectara algún problema con mi punto de vista sobre el asunto - por qué esto no funciona, por qué no está dando los beneficios de DDD, por qué no es una buena idea en general.

The blogpost is here (No creo que deba copiarlo y pegarlo en SO - si cree que debería, dígamelo).

Sé que la pregunta es subjetiva, pero está dirigida a reunir las opiniones más predominantes.

(soy el etiquetado de Java, ya que los marcos son discutidos marcos de Java)

Answer 1

Acabo de pasar un año de mi vida desgarrando una aplicación para eliminar un anti-patrón de dominio anémico y su mal uso de Hibernate.

Puedo decir sin ninguna duda que el código que viene como resultado de DDD es mucho más fácil de entender y refactorizar. En nuestro caso, la eliminación de miles de getters innecesarios &, el aumento de la encapsulación, la concentración de la lógica empresarial y la simplificación resultante (dramática) de las capas de servicios que acompañan a DDD han hecho que el sistema sea mucho más fácil de mantener que ahora creo que podremos terminarlo, mientras que antes se arrastraba hacia siempre. Hemos reducido el recuento de líneas de esta aplicación en un 50% sin eliminar ninguna funcionalidad.

También creo que el objetivo de una herramienta ORM es que mi lógica comercial esté despejada con el código de persistencia. Cuando teníamos un modelo de dominio anémico, teníamos un DAO para cada clase de dominio, ahora tenemos un pequeño puñado de DAO como punto de entrada para CRUD en las clases de dominio "principales", pero las otras clases de dominio "menores" son manejadas por sus padres ... no porque la lógica de persistencia esté en el padre sino porque Hibernate reacciona de manera transparente a la lógica del negocio y hace que todo funcione.

En resumen, no puedo responder a esta pregunta porque estoy totalmente de acuerdo con su publicación 100% ... y la estoy viviendo todos los días.

Answer 2

Vamos con el enfoque "modelo anémica" para que podamos volver a utilizar los mismos modelos con diferente lógica de negocio. Sin embargo, sí incluimos cálculos y métodos de ayuda dentro de nuestros modelos si son aplicables para todos los casos. Pero no inyectamos nada en nuestros modelos y no inyectamos nuestros modelos en IoC.

Answer 3

Personalmente, no estoy convencido de que la parte sobre la inyección de objetos de depósito en los objetos de dominio (es decir, las entidades persistentes) sea necesaria con Spring e Hibernate. Hibernate ya está proporcionando colecciones persistentes que pueden hacer cargas diferidas, por lo que ya tiene la capacidad de atravesar el modelo de dominio de una manera que separa la infraestructura de acceso a datos de la lógica comercial. No veo qué valor agregan los depósitos de tachuelas en el modelo de dominio.

EDITAR: Oops, publicado esto antes de leer todo el artículo. Ahora que he leído toda la publicación del blog, creo que estoy de acuerdo con ella. Me gusta la parte que recomienda hacer sin DTO siempre que sea posible.