Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

[Dúvida] Regra de adoção: melhor na service ou no domínio?

Pessoal, fiquei com uma dúvida conceitual sobre a parte de exceptions na AdocaoService.

No exemplo do curso, a regra de negócio (como “não permitir solicitar adoção de um pet já adotado”) está sendo validada diretamente na service. Funciona, claro, mas estudando um pouco de arquitetura hexagonal + DDD, vi que esse tipo de regra talvez fizesse mais sentido dentro do domínio, por exemplo na própria entidade Pet ou em um domain service.

A ideia seria que o próprio domínio garantisse suas invariantes, algo como:

o Pet sabe se pode ou não ser adotado
a aplicação (service/use case) só orquestra o fluxo

Isso evitaria duplicação de regras e deixaria o modelo mais consistente ao longo do tempo.

Entendo que no contexto didático simplificar colocando na service pode ajudar no começo, mas queria saber:

  • Em um cenário mais próximo do mundo real, vocês também levariam esse tipo de regra para o domínio?
  • Ou manteriam na service mesmo por questão de simplicidade?

Curioso pra ouvir a opinião de vocês e do instrutor.

2 respostas
solução!

Oi!

Essa é uma excelente reflexão, Aldeny. Você tocou em um ponto central que separa o código que apenas funciona do código que é fácil de sustentar a longo prazo.

A resposta curta é: sim, no mundo real, buscamos levar o máximo de regras para o domínio, mas existe uma linha tênue entre o que pertence à entidade e o que pertence à camada de serviço.

Vamos analisar as três validações que você mencionou sob a ótica do DDD e da arquitetura limpa:

1. Regra de estado interno (Domínio - Entidade)

O caso do "Pet já adotado" é o exemplo clássico de uma regra que deve estar na entidade Pet.

  • Por que: O fato de um pet estar disponível ou não é um estado intrínseco dele.
  • Abordagem: Em vez de a AdocaoService fazer um if, o ideal seria chamar um método no modelo, como pet.validarDisponibilidade(). Se o pet estiver adotado, a própria entidade lança a exceção. Isso protege o objeto de estados inválidos, independentemente de quem o chame.

2. Regra de estado do sistema (Domínio - Domain Service)

A regra "Pet com solicitação em andamento" e "Tutor com 2 adoções aprovadas" são um pouco diferentes.

  • O desafio: A entidade Pet sozinha não sabe se existem registros na tabela de adoções no banco de dados. Ela não deve injetar repositórios.
  • Abordagem: Aqui entram os Domain Services. Você pode criar uma classe de domínio que recebe os repositórios necessários para realizar essa conferência antes de autorizar a criação da adoção. Assim, a regra de negócio continua no domínio, e a AdocaoService (que é de aplicação) apenas orquestra: busca os objetos, chama o serviço de domínio e salva o resultado.

Quando manter na Service?

Em projetos pequenos ou quando a regra é puramente de fluxo de aplicação (como checar permissões de usuário ou enviar um e-mail após a ação), a Service é o lugar certo.

No curso, manter na Service ajuda a focar no aprendizado de como lançar e tratar exceções sem adicionar a complexidade de padrões de projeto mais avançados logo de cara. Mas, para sua carreira, exercitar esse olhar de "como posso enriquecer meu domínio?" fará muita diferença na qualidade das suas entregas.

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Oi Lorena, obrigado pelos esclarescimento!