Exceções no DDD

Estou aprendendo DDD e estou pensando em lançar exceções em determinadas situações. Eu entendo que um objeto não pode entrar em um estado ruim; portanto, aqui as exceções são boas, mas em muitos exemplos as exceções também são lançadas, por exemplo, se estamos tentando adicionar um novo usuário com o email existente no banco de dados.

public function doIt(UserData $userData)
{
    $user = $this->userRepository->byEmail($userData->email());
    if ($user) {
        throw new UserAlreadyExistsException();
    }

    $this->userRepository->add(
        new User(
            $userData->email(),
            $userData->password()
        )
    );
}

Portanto, se o usuário com este email existir, no serviço de aplicativos podemos capturar uma exceção, mas não devemos controlar a operação do aplicativo usando o bloco try-catch.

Qual a melhor maneira para isso?

Vamos começar com uma breve revisão do espaço do problema: Um dos princípios fundamentais do DDD é colocar as regras de negócios o mais próximo possível dos locais onde elas precisam ser aplicadas. Este é um conceito extremamente importante porque torna seu sistema mais "coeso". Mover regras "para cima" geralmente é um sinal de um modelo anêmico; onde os objetos são apenas sacos de dados e as regras são injetadas com esses dados a serem aplicados.

Um modelo anêmico pode fazer muito sentido para os desenvolvedores que estão começando com o DDD. Você cria um Usermodelo e um EmailMustBeUnqiueRuleque são injetados com as informações necessárias para validar o email. Simples. Elegante. A questão é que esse "tipo" de pensamento é de natureza fundamentalmente processual. Não DDD. O que acaba acontecendo é que você fica com um módulo com dezenas de Rulespacotes organizados e encapsulados, mas eles são completamente desprovidos de contexto ao ponto em que não podem mais ser alterados porque não está claro quando / onde eles são aplicados. Isso faz sentido? Ele pode ser auto-evidente que um EmailMustBeUnqiueRuleserá aplicado na criação de um User, mas o que dizer UserIsInGoodStandingRule?. Lenta mas seguramente, a granularização da extração doRulesFora do contexto deles, você fica com um sistema difícil de entender (e, portanto, não pode ser alterado). As regras devem ser encapsuladas somente quando a trituração / execução real é tão detalhada que seu modelo começa a perder o foco.

Agora, vamos à sua pergunta específica: o problema de ter o Service/ CommandHandlerthrow the Exceptioné que sua lógica de negócios está começando a vazar ("para cima") do seu domínio. Por que seu Service/ CommandHandlernecessidade de saber um e-mail deve ser único? A camada de serviço de aplicativo é geralmente usada para coordenação e não para implementação. A razão para isso pode ser ilustrada simplesmente se adicionarmos um ChangeEmailmétodo / comando ao seu sistema. Agora, os dois métodos / manipuladores de comando precisariam incluir sua verificação exclusiva. É aqui que um desenvolvedor pode ser tentado a "extrair" um EmailMustBeUniqueRule. Como explicado acima, não queremos seguir esse caminho.

Algumas informações adicionais podem nos levar a uma resposta mais DDD. A exclusividade de um email é uma invariável que deve ser aplicada em uma coleção de Userobjetos. Existe um conceito em seu domínio que represente uma "coleção de Userobjetos"? Eu acho que você provavelmente pode ver para onde estou indo aqui.

Para este caso específico (e muitos outros envolvendo a imposição de invariantes entre coleções), o melhor lugar para implementar essa lógica será o seu Repository. Isso é especialmente conveniente porque você Repositorytambém "conhece" a parte extra da infraestrutura necessária para executar esse tipo de validação (o armazenamento de dados). No seu caso, eu colocaria essa verificação no addmétodo Isso faz sentido, certo? Conceitualmente, é esse método que realmente adiciona um Userao seu sistema. O armazenamento de dados é um detalhe de implementação.

Você pode impor a validação em todas as camadas do seu aplicativo. Onde impor quais regras dependem do seu aplicativo.

Por exemplo, as entidades implementam métodos que representam regras de negócios, enquanto os casos de uso implementam regras específicas para seu aplicativo.

Se você estiver criando um serviço de e-mail como o Gmail, é possível argumentar que a regra "os usuários devem ter uma única e-mailadress" é uma regra comercial.

Se você estiver criando um processo de registro para um novo sistema de CRM, essa regra provavelmente será melhor implementada em um caso de uso, já que essa regra também fará parte do seu caso de uso. Além disso, também pode ser mais fácil testar, pois é possível stubar facilmente as chamadas do repositório nos testes de casos de uso.

Para segurança adicional, você também pode aplicar essa regra em seu repositório.