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

14

Supongamos que estamos modelando un formulario utilizando DDD; el formulario puede tener cierto tipo de reglas comerciales asociadas, tal vez deba especificar un ingreso si no es un estudiante y se le exige que incluya a sus hijos si indica que está casado. Y si especificó un país, debería tener un país válido.

¿Este tipo de validación vive en el dominio o capa de aplicación? Algunas otras cuestiones que estaba considerando:

  • Ciertos marcos, como Laravel, proporcionan reglas de validación que pueden validar la entrada antes de que una solicitud llegue al controlador. ¿Se rompe la DDD si la validación se realiza a ese nivel?

  • Para casos como determinar si el país es válido, normalmente solo consultaré una tabla de base de datos de todos los países del mundo. Sin embargo, en DDD, es probable que esto se haga (a mi entender) en la capa de dominio. ¿Se permite que la capa de dominio acceda a la base de datos o debo usar una búsqueda que no sea de SQL para determinar un país válido?

  • ¿Es necesario validar la entrada tanto en la aplicación como en la capa de dominio?

pregunta Extrakun 06.04.2016 - 05:58

3 respuestas

17
  

¿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.

    
respondido por el VoiceOfUnreason 06.04.2016 - 16:50
4

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.

    
respondido por el aryeh 14.04.2016 - 07:15
0

¿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.

    
respondido por el Euphoric 06.04.2016 - 08:11

Lea otras preguntas en las etiquetas