Martin Fowler considera el modelo de dominio anémico como un anti-patrón.

Rodar el Modelo de Persistencia como el Modelo de Dominio parece estar muy apagado también debido aImpedancia relacional de objetos. En aras de la persistencia y la normalización, tendemos a dividir las clases en pequeñas partes muy pequeñas, y los métodos de bofetadas que se encuentran encima de estas clases son ridículos. Además, la persistencia rara vez cambia, pero la lógica de negocios cambia un poco.

Por lo tanto, necesitamos un DomainModel que se base en el modelo de persistencia (en lugar de ser el mismo). Este modelo de dominio contendrá las propiedades y el método de la lógica de negocios.

Pero ahora estos Modelos de Dominio aún están detrás del servicio, y para poder exponerlos al mundo exterior, necesitamos convertirlos a DTO.

Lo estamos haciendo manny mappings aquí.

Persistencia al modelo de dominioPara convertir el modelo de dominio en DTO para pasar de un servicio a otro

No termina ahí, ya que es posible que el DTO deba asignarse a ViewModel.

Todo eso y el problema de duplicar la lógica de validación aún no desaparecen, porque el cliente desea la validación en tiempo real. ViewModel no sabe nada acerca de la validación, por lo que en un SPA, por ejemplo, se ve obligado a volver a escribir la lógica de validación nuevamente, en el lado del cliente (generalmente en javascript).

Además, los servicios son por naturaleza sin estado (orientados a mensajes o RPC), por lo que estamos haciendo todos estos mapeos, entre Persistence, OO y luego volvemos a Procedural, ¿para qué beneficio? ¿Cómo justificaría el costo en términos prácticos de la mayoría del presupuesto de TI?

Entiendo que tener DDD completo, con raíces agregadas, modelos de dominio, etc. sería "genial", pero ¿cómo puede justificar el costo y el impacto en la productividad de los desarrolladores?

anti-patrón (o antipattern) es un patrón que se usa en operaciones sociales o de negocios o en ingeniería de software que puede usarse comúnmente, pero en la práctica es ineficaz y / o contraproducente.

Y si es así, DDD y Rich Domain Model no encajarían en la definición anti-patrón anterior al Modelo de dominio "Lean". Lo siento, desprecio la palabra cargada, "Anemia".

Al mantener el Modelo de Dominio, "Lean", usted realmente permite que se comparta sin violar el "Principio de Dependencia Abstracta", "No Se Repita" y el proceso lento, tedioso y propenso a errores de asignar un soporte de datos a otro. y cualquier prueba de unidad asociada que vaya más allá de eso (a menos que esté pensando en hacer un mapeo sin pruebas de unidad y espere lo mejor).