Validación con DDD en aplicación SOA usando IoC

Question

En mi capa de fachada de servicio, tengo una clase de servicio con un método/operación que acepta un objeto DTO (contrato de datos). AutoMapper se usa para asignar este DTO en una instancia de mi objeto de dominio para aplicar cualquier cambio. La solicitud se pasa a mi servicio de dominio que hace el trabajo real. Esto es lo que el método podría ser: propiedades

public EntityContract AddEntity(EntityContract requestContract) 
{ 
    var entity = Mapper.Map<EntityContract, Entity>(requestContract); 

    var updatedEntity = Service.AddEntity(entity); 

    var responseContract = Mapper.Map<Entity, EntityContract>(updatedEntity); 

    return responseContract; 
} 

el servicio y Mapper se establecen mediante la inyección de constructor con Unity como el contenedor IoC.

En la realización de la operación, el servicio de dominio hace cambios a la entidad, entonces utiliza un repositorio para persistir los cambios como:

public Entity AddEntity(Entity entity) 
{ 
    // Make changes to entity 

    Repository.Add(entity); 

    // Prepare return value 
} 

El repositorio también se ajusta mediante la inyección de constructor.

El problema es que los datos quedan inmediatamente disponibles para otros clientes una vez que se han conservado, por lo que debo asegurarme de que no se conservan datos no válidos. He leído el "libro azul" de DDD (Evans) y Nilsson, y no tengo claro qué enfoque de validación debo tomar.

Si mi objetivo es evitar que la entidad entre en un estado no válido, ¿debo validar entityContract en mi método de servicio para asegurar que todas las reglas estén satisfechas antes de pasar la solicitud al servicio de mi dominio? Dudo en hacerlo porque parece que estoy rompiendo la encapsulación teniendo estas reglas definidas en la fachada del servicio.

La razón por la que estamos utilizando una delgada capa de fachada delegando a los servicios de dominio es que estamos exponiendo interfaces de curso en nuestra API, pero admitimos la reutilización a través de la composición de los servicios de dominio de grano fino. Teniendo en cuenta que los servicios de fachada múltiple pueden estar llamando al mismo método de servicio de dominio, tal vez sería mejor delegar estas reglas en el servicio de dominio para que sepamos que cada uso está validado. ¿O debería validar en ambos lugares?

También podría colocar protectores en los reguladores de propiedades que impiden que los valores inaceptables pongan la entidad en un estado no válido. Esto significaría que AutoMapper fallaría al tratar de asignar un valor no válido. Sin embargo, no ayuda cuando no se asigna ningún valor.

Todavía no puedo dejar de pensar que estas reglas son parte del comportamiento de la entidad y determinar si el objeto es válido debe ser encapsulado dentro de la entidad. ¿Esto esta mal?

Por lo tanto, primero debo determinar cuándo y dónde realizo estas comprobaciones de validación. Entonces necesito descubrir cómo implementar con DI para que las dependencias estén desacopladas.

¿Qué sugerencias puede proporcionar?

Answer 1

He leído el "libro azul" de DDD (Evans), así como Nilsson y no soy claro qué enfoque de validación que debería tomar.

El libro azul aborda el problema desde un ángulo diferente. Creo que el término 'Validación' no se usa porque es peligroso overgeneralization. Un mejor enfoque es pensar invariantes del objeto, no la validación. Los objetos (no solo en DDD) deben aplicar sus propios invariantes internos. No es UI o servicios o contratos o mapeadores o 'marcos de validación' o cualquier otra cosa que sea externa a los objetos. Las invariantes se aplican internamente.Puede encontrar estas respuestas útiles: 1, 2, 3, 4.

También podría poner guardias en los emisores de propiedad que impiden valores inaceptables de tener que poner la entidad en un estado válido. Esto significaría que AutoMapper fallaría al intentar asignar un valor no válido.

Probablemente no le importe que AutoMapper falle o que use AutoMapper. Los objetos de dominio deben encapsular e imponer sus invariantes internas y lanzar una excepción si se realiza el intento de romperla. Es muy simple y no debe comprometer la simplicidad y la expresividad de los objetos de su dominio debido a algunos problemas de infraestructura. El objetivo de DDD no es satisfacer los requisitos de AutoMapper ni de ningún otro marco. Si el marco no funciona con los objetos de tu dominio, no lo uses.

Answer 2

Existen dos tipos de validación: consistencia

1. Objeto: es la responsabilidad de las entidades. Las entidades no deben permitir que establezcas un estado no válido, las dependencias deben aplicarse, los valores deben estar dentro del rango. debe diseñar los métodos y las propiedades de las clases y los constructores para no permitir el estado no válido.

2. Validación de roles comerciales: este tipo de validación requiere el procesamiento del servidor, como verificar la disponibilidad de la id, la exclusividad del correo electrónico y demás. estos tipos de validaciones deben procesarse en el servidor como validadores o especificaciones antes de la persistencia.