Cómo evitar una capa de dominio anémica y aún tener validación y reglas comerciales ricas

Question

Si tiene un objeto de dominio y desea hacer algo útil y central para la responsabilidad de ese objeto de dominio, como asegurarse de que sea válido, a veces necesita acceder el estado de los objetos relacionados para realizar esta validación.

Cómo evitar el objeto de dominio que necesita llamar a un repositorio o capa de acceso a datos? No siempre puede recorrer las relaciones de recopilación, incluso con la carga diferida, debido al rendimiento, y a menudo desea ejecutar consultas en el objeto de dominio. Puede implementar la implementación del repositorio de la dependencia en el dominio, pero no es realmente puro y complica las pruebas.

Siempre he relajado las cosas y he permitido el acceso desde el dominio a un repositorio que usa DI. No he visto ejemplos claros de cómo tener una capa de dominio "pura" en una aplicación compleja que tampoco es anémica y tiene una capa de servicio/aplicación que hace todo el ruido y juega con lo que deberían ser las entrañas de los objetos de dominio.

Answer 1

• Si el objeto es un objeto de valor, debería ser inmutable y validado durante la construcción.

• Si el objeto es un agregado de raíz, y que su propio estado es suficiente para decirle si es válido o no, habría que agregar un método de validación en él, que cascadas a través de la agregación.

• Por último, y creo que es su principal preocupación, si necesita acceder a varios objetos relacionados (que son no en el mismo agregado) para asegurar una de ellas es válida, necesita definitivamente a deportar esta lógica en un servicio de validación específico.

Realmente creo que inyectar servicios y repositorios en entidades no es la mejor opción. Crear servicios dedicados parece más apropiado, y no veo por qué lo llevará a tener objetos de dominio anémicos.

En resumen, si puede validar su estado de objeto sin depender de servicios o repositorios, permita que el objeto se encargue de ello, en el nivel de raíz agregado. Cuando necesite consultar servicios o repositorios, o cuando necesite otras entidades, entonces considere seriamente mover esta lógica fuera del objeto.

Answer 2

Respondí una pregunta similar hace unas horas. La respuesta contiene una guía que uso cuando trato de enriquecer mi modelo con lógica y comportamiento sin ensuciarlo con dependencias relacionadas con la tecnología. Having trouble putting real-world logic into the DDD domain layer

la respuesta también enlaces a otros recursos útiles.

Buena suerte y no dude en enviarme un correo electrónico o preguntarme acerca de DDD y evitar los modelos de Anemic. Es un tema interesante donde las personas tienden a resolver esto de diferentes maneras.