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

15

Suponha que estamos modelando um formulário usando DDD; o formulário pode ter certos tipos de regras de negócios associados a ele - talvez você precise especificar uma renda se não for estudante, e deve listar seus filhos se indicar que é casado. E se você especificou um país, então 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:

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

  • Para casos como determinar se o país é válido, normalmente consultarei apenas uma tabela de banco de dados de todos os países do mundo. No entanto, no DDD, é provável (do meu ponto de vista) que isso seja feito na camada de domínio. A camada de domínio tem permissão para acessar 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 aplicação e na camada de domínio?

por Extrakun 06.04.2016 / 05:58
fonte

3 respostas

17

Does this kind of validation lives in the domain or application layer?

Aplicativo. O termo de pesquisa mágica que você deseja é anti camada de corrupção

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

Exemplo: um comando DepositMoney provavelmente incluiria um valor e um tipo de moeda. A representação do DTO provavelmente expressaria o valor como um inteiro e o código da moeda como uma string. A camada anti-corrupção converteria o DTO em um tipo de valor 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).

Tendo analisado com êxito o comando em tipos que o modelo de domínio compreende, o comando é executado no domínio, que ainda pode rejeitar o comando com base no argumento de que violaria a invariante do negócio (a conta ainda não existe, a conta está bloqueado, esta conta em particular não tem permissão para usar essa moeda? etc).

Em outras palavras, a validação do negócio ocorrerá no modelo de domínio, depois que a camada anti-corrupção validar as entradas.

A implementação das regras de validação normalmente será executada no construtor do tipo de valor ou no método de fábrica usado para construir o tipo de valor. Basicamente, você restringe a construção dos objetos para garantir sua validade, isolando a lógica em um lugar e invocando-a nos limites do processo.

    
por 06.04.2016 / 16:50
fonte
4

Seu modelo de domínio do problema 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 o seu domínio interage com seres humanos (por meio de telas, formulários, etc.), não é necessária nenhuma 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 a remoção de colaborações entre objetos.

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

Observação: não há nenhum conceito no DDD de "modelagem" do seu formulário.

    
por 14.04.2016 / 07:15
fonte
0

O estado específico tornaria a entidade do 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. Frequentemente, queremos validar cedo, para que o usuário não precise esperar muito. É por isso que a validação é frequentemente colocada na lógica da aplicação.

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

    
por 06.04.2016 / 08:11
fonte