No DDD, a lógica do aplicativo de validação ou a lógica do domínio?

Suponha que estamos modelando um formulário usando DDD; o formulário pode ter certos tipos de regras de negócios associadas a ele - talvez você precise especificar uma renda se não for um estudante e precisar listar seus filhos se indicar que é casado. E se você especificou um país, ele deve ter um país válido.

Esse tipo de validação reside no domínio ou na camada de aplicativo? Algumas outras questões que eu estava considerando:

• Certas estruturas, como o Laravel, fornecem regras de validação que podem validar a entrada antes que uma solicitação atinja o controlador. Ele quebra o DDD se a validação for feita nesse nível?

• Para casos como determinar se o país é válido, geralmente apenas consultarei uma tabela de banco de dados de todos os países do mundo. No entanto, no DDD, é provável (na minha opinião) que isso seja feito na camada de domínio. É permitido que a camada de domínio acesse o banco de dados ou devo usar uma pesquisa não SQL para determinar um país válido?

• É necessário validar a entrada na camada do aplicativo e do domínio?

Esse tipo de validação reside no domínio ou na camada de aplicativo?

Aplicação. O termo de pesquisa mágico que você deseja é camada anti-corrupção

Normalmente, a mensagem recebida pelo seu aplicativo terá algum sabor do DTO. Sua camada anticorrupção normalmente cria tipos de valor que o domínio reconhecerá. O comando real enviado para o modelo de domínio será expresso em termos de tipos de valores validados.

Exemplo: um comando DepositMoney provavelmente incluiria um valor e um tipo de moeda. A representação do DTO provavelmente expressaria a quantidade como um número inteiro e o código da moeda como uma sequência. A camada anticorrupção converteria o DTO em um tipo de valor de Depósito, que incluiria um Valor validado (que não deve ser negativo) e um CurrencyCode validado (que deve ser um dos códigos suportados no domínio).

Depois de analisar com êxito o comando em tipos que o modelo de domínio entende, o comando é executado no domínio, que ainda pode rejeitar o comando, alegando que violaria a invariante comercial (a conta ainda não existe, a conta está bloqueada, essa conta em particular não tem permissão para usar essa moeda etc.).

Em outras palavras, a validação de negócios ocorrerá no modelo de domínio, depois que a camada anticorrupção valida as entradas.

A implementação das regras de validação normalmente permanecerá no construtor do tipo de valor ou dentro do método de fábrica usado para construir o tipo de valor. Basicamente, você restringe a construção dos objetos para que eles sejam garantidos como válidos, isolando a lógica em um local e invocando-a nos limites do processo.

Seu modelo de domínio com problemas inclui suas regras de negócios de domínio. Regras de negócios são restrições nos elementos do modelo. Eles significam que um elevador não se move com a porta aberta, que mercadorias perecíveis não são carregadas em um contêiner não refrigerado e que um pedido cancelado não é enviado.

Isso não significa que, quando seu domínio interage com seres humanos (por meio de telas, formulários etc.), não é necessário validação ou assistência. Apenas perceba que é opcional.

Considere que existem dois tipos de regras de negócios: - regras de propriedade que restringem os atributos de um objeto e regras de colaboração que restringem a adição e remoção de colaborações entre objetos.

As regras de negócios são diferentes das regras lógicas, relacionadas à sua linguagem de programação e verificam se os valores foram fornecidos e não são nulos, etc.

Nota: não há conceito no DDD de "modelar" seu formulário.

O estado específico tornaria a entidade modelo inválida? Se sim, o modelo deve impedir que a entidade chegue a esse estado. Isso significa que o modelo deve saber como se validar.

Mas há um pequeno problema: a validação do modelo geralmente acontece tarde demais. Muitas vezes, queremos validar com antecedência, para que o usuário não precise esperar muito. É por isso que a validação é frequentemente colocada na lógica do aplicativo.

Quanto ao contexto de validação: Não há problema de a entidade poder consultar dados adicionais. Mas não deve se importar de onde vêm esses dados. Ele não se importa se vem do SQL, File ou é apenas codificado. É por isso que existem repositórios. O domínio define que tipo de consulta precisa e permite que outra pessoa cuide da implementação.

A camada de domínio deve conter toda a lógica de validação. Apresentação, camadas anticorrupção ou outras camadas dependentes devem refletir isso.