Regras de negocio no DDD

Ola Thiago.

Quando temos uma busca em uma base, ou mesmo em uma API, é uma integração de infraestrutura, e ficaria na camada de infra. O modelo não poderia depender da infra.

No curso temos 3 pacotes dentro de um domínio, e ela esta seguindo o conceito de Clean Architecture

• infra
• aplicação
• domínio

Assim, o dominio pode ser usado pela aplicação e infra, mas o contrario não: domínio não usaria e nem dependeria da aplicação e infra. Isso é comentado aqui nesse topico a partir do 5min https://cursos.alura.com.br/course/java-domain-driven-design-conceitos/task/82977

No seu exemplo, teríamos uma classe de serviço no pacote de aplicação com a regra da sua busca, que chamaria a interface de repositorio acessando o banco de dados. A tela (ou controlador ou o cliente) acessaria então esse serviço. Mas veja que a aplicação é uma cada de fluxo, que pode organizar os acessos dos dados e a chamada de regras que estão do domínio. As regras de negócio ficam no domínio.

Temos um curso de aqui https://cursos.alura.com.br/course/java-clean-architecture/

A busca ao banco de dados OK, eu entendi que é na camada de infra, e tambem entendi que a camada de dentro nao pode acessar a de fora OK. Minha duvida é em relação a regra de negocio. E a regra que eu usei de exemplo é uma que justamente nao pode ficar dentro do aluno, pois ela precisa fazer uma consulta no banco de dados.

Então usando a didática usada no curso, a equipe de negocio passou para o pessoal do desenvolvimento que não pode deixar dois alunos com o mesmo cpf cadastrado.

onde usando o DDD e o clean architeture fica essa regra para nao ferir as camadas? É na camada de Use Case?

foi isso que quis perguntar.

No DDD, essa regra poderia ficar no serviço de domínio (que faz parte do domínio). Basicamente, o seu serviço de domínio faria a chamada para um método do repositório, perguntando a existência daquele usuário para o repositório. Acredito que o mesmo possa ser feito seguindo o Clean Architecture na camada de Use Cases.

Existem várias maneiras de se fazer isso, mas acredito que o ponto central é de se respeitar o "D" do SOLID, que seria o Dependency Inversion Principle, ou seja, na sua camada de domínio existirá uma interface/classe abstrata que definirá esse contrato de comunicação com seu repositório de dados. A implementação/extensão dessa interface/classe abstrata pode acontecer de várias maneiras, por ex.: respeitando o modelo de portas e adaptadores, ou simplesmente uma classe sua fazendo a implementação dessa interface na camada de infraestrutura, a fim de ser injetada por um container de injeção de dependência.