En DDD, ¿es la lógica de la aplicación de validación o la lógica del dominio?

  

¿Este tipo de validación vive en el dominio o capa de aplicación?

Aplicación. El término de búsqueda mágica que desea es anti capa de corrupción

Por lo general, el mensaje recibido por su aplicación será similar a DTO. Su capa anticorrupción normalmente creará tipos de valor que el dominio reconocerá. El comando real enviado al modelo de dominio se expresará en términos de tipos de valores validados.

Ejemplo: un comando DepositMoney probablemente incluiría una cantidad y un tipo de moneda. La representación DTO probablemente expresaría la cantidad como un entero y el código de moneda como una cadena. La capa anticorrupción convertiría la DTO en un tipo de valor de depósito, que incluiría una cantidad validada (que debe ser no negativa) y un código de moneda validado (que debe ser uno de los códigos admitidos en el dominio).

Después de haber analizado con éxito el comando en tipos que el modelo de dominio entiende, el comando se ejecuta en el dominio, que aún puede rechazar el comando debido a que violaría la invariante del negocio (la cuenta aún no existe, la cuenta está bloqueado, esta cuenta en particular no tiene permiso para usar esa moneda? etc).

En otras palabras, la validación de negocios ocurrirá en el modelo de dominio, después de que la capa anticorrupción valide las entradas.

La implementación de las reglas de validación normalmente se realizará en el constructor del tipo de valor o dentro del método de fábrica utilizado para construir el tipo de valor. Básicamente, restringe la construcción de los objetos para garantizar que sean válidos, aislando la lógica en un lugar e invocándola en los límites del proceso.

Su modelo de dominio de problema incluye las reglas comerciales de su dominio. Las reglas de negocio son restricciones sobre los elementos del modelo. Significan que un ascensor no se mueve con la puerta abierta, que los productos perecederos no se cargan en un contenedor no refrigerado y que no se envía un pedido cancelado.

Eso no significa que cuando su dominio interactúa con humanos (a través de pantallas, formularios, etc.) no es necesario que haya validación o asistencia. Solo date cuenta que es opcional.

Tenga en cuenta que existen dos tipos de reglas de negocio: reglas de propiedad que restringen los atributos de un objeto y reglas de colaboración que restringen la adición y eliminación de colaboraciones entre objetos.

Las reglas de negocios son diferentes de las reglas lógicas, que están relacionadas con su lenguaje de programación y verifican que los valores se hayan proporcionado y que no sean nulos, etc.

Nota: no hay ningún concepto en DDD de "modelar" su formulario.

¿Un estado específico haría que la entidad del modelo fuera inválida? Si es así, entonces el modelo debe evitar que la entidad llegue a ese estado. Eso significa que el modelo debe saber validarse.

Pero hay un pequeño problema: la validación del modelo a menudo sucede demasiado tarde. A menudo, queremos hacer la validación antes, para que el usuario no tenga que esperar demasiado. Es por eso que la validación a menudo se coloca en la lógica de la aplicación.

En cuanto al contexto de validación: no hay problema de que la entidad pueda consultar datos adicionales. Pero no debería importar de dónde provienen esos datos. No importa si viene de SQL, File o simplemente está codificado. Por eso existen los repositorios. El dominio define qué tipo de consulta necesita y permite que otra persona se encargue de la implementación.