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

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

¿Este tipo de validación vive en el dominio o en la capa de aplicación? Algunos otros problemas 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. ¿Rompe DDD si la validación se realiza a ese nivel?

• Para casos como determinar si el país es válido, generalmente solo consultaré una tabla de base de datos de todos los países del mundo. Sin embargo, en DDD, esto es probable (según tengo entendido) que se haga 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 SQL para determinar un país válido?

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

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

Solicitud. El término de búsqueda mágico que desea es la capa anticorrupción

Por lo general, el mensaje recibido por su aplicación será una muestra de DTO. Su capa anticorrupción generalmente 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 número entero y el código de moneda como una cadena. La capa anticorrupción convertiría el DTO en un tipo de valor de Depósito, que incluiría una Cantidad validada (que no debe ser negativa) y un Código de moneda validado (que debe ser uno de los códigos admitidos en el dominio).

Después de analizar con éxito el comando en tipos que el modelo de dominio comprende, el comando se ejecuta en el dominio, que aún puede rechazar el comando porque violaría el negocio invariante (la cuenta aún no existe, la cuenta está bloqueada, esta cuenta en particular no tiene permitido usar esa moneda? etc).

En otras palabras, la validación comercial va a suceder 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 invocando en los límites del proceso.

Su modelo de dominio problemático incluye sus reglas comerciales de dominio. Las reglas de negocio son restricciones en 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 necesita validación ni asistencia. Solo date cuenta de que es opcional.

Tenga en cuenta que hay 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 comerciales 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 existe un concepto en DDD de "modelar" su formulario.

¿El estado específico invalidaría la entidad modelo? En caso afirmativo, el modelo debe evitar que la entidad llegue a ese estado. Eso significa que el modelo debe saber cómo validarse.

Pero hay un pequeño problema: la validación del modelo a menudo ocurre demasiado tarde. A menudo, queremos hacer la validación temprano, para que el usuario no tenga que esperar demasiado. Es por eso que la validación a menudo se pone 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 importarle de dónde provienen esos datos. No le importa si proviene de SQL, File o simplemente está codificado. Por eso existen repositorios. El dominio define qué tipo de consulta necesita y permite que otra persona se encargue de la implementación.

La capa de dominio debe contener toda la lógica de validación. La presentación, las capas anticorrupción u otras capas dependientes deberían reflejar eso.