DDD - Validación de la restricción única

Question

En DDD nunca debe permitir que las entidades ingresen un estado no válido. Dicho esto, ¿cómo manejas la validación de una restricción única?

La creación de una entidad no es un problema real. Pero supongamos que tiene una entidad que debe tener un nombre único y hay mil instancias de este tipo de entidad: no están en la memoria sino que están almacenados en una base de datos. Ahora supongamos que quieres cambiar el nombre de una instancia.

No puede usar un setter ... el objeto podría entrar en un estado no válido - debe validar contra la base de datos.

¿Cómo maneja este escenario en un entorno web?

Answer 1

Una restricción de exclusividad se puede reducir a una excepción de persistencia, en lugar de verse como un "estado no válido". No es un estado inválido hasta que el objeto persista. La unicidad solo tiene mucho sentido en el contexto de la persistencia. Siendo realistas, puede poner este tipo de regla en su mecanismo de validación para ayudar a reducir la probabilidad de este error, pero en cualquier sistema multiusuario real, no se le puede garantizar la unicidad hasta que una unidad de trabajo exitosa complete la acción de persistencia.

Por lo que es posible que desee esto en su mecanismo de validación, pero debe aplicarlo en su capa de persistencia.

Generalmente soy un fan de DDD como metodología, pero creo que "no permitir que los objetos entren en estados inválidos" puede requerir algunas abstracciones tortuosas. En una aplicación web, tener una "Vista Modelo" por separado es una posible solución, como una capa intermedia antes de la persistencia, pero normalmente no hago eso hasta que estoy convencido de que me causará menos dolor que la alternativa más simple.