Como lidar com erros de pós-validação no comando (DDD + CQRS)

Por exemplo, quando você enviar um formulário Register, você tem que verificar no Domain Model( WriteModelem CQRS) que ele está em um estado válido (exemplo, email sintaxe de endereço, idade, etc).

Então você cria um Commande envia para a Command Bus.

Eu entendo que os comandos não devem retornar nada.

Então, como você lida com um erro além Command Bus? (Por exemplo, um usuário registrou 1 segundo antes com o mesmo username/email).

Como você sabe que o comando falhou e como você sabe o erro?

Eu entendo que os comandos não devem retornar nada.

Essa é uma visão, mas não está totalmente imutável. Considere gravações (PUT, POST, DELETE) em HTTP - todas essas mensagens são comandos, no sentido de que são mensagens com solicitação de mudança de estado do recurso e, no entanto, todas elas retornam respostas.

Então, como você lida com um erro além do Command Bus? (Por exemplo, um usuário se registrou 1 segundo antes com o mesmo nome de usuário / email).

Como você sabe que o comando falhou e como você sabe o erro?

Portanto, em um caso em que você está se comunicando diretamente com o manipulador de comandos, uma mensagem retornada é uma maneira perfeitamente razoável de reconhecer que o comando foi recebido e processado.

Se você estiver usando um middleware, como um barramento, que o impede de se comunicar diretamente com o destino, sugiro que você procure padrões de mensagens assíncronos - como você faz com que o manipulador de comandos envie uma mensagem de volta ao chamador?

Uma idéia é assinar o resultado do comando; isso se baseia em algumas das idéias dos padrões de integração corporativa da Hohpe. A idéia básica é que, como o cliente está familiarizado com a mensagem de comando enviada, está bem posicionado para assinar quaisquer novas mensagens publicadas como conseqüência da mensagem de comando. O manipulador de comandos, depois de salvar os dados no livro de registro, publica eventos anunciando que a alteração foi bem-sucedida e o cliente se inscreve nesses eventos - reconhecendo os eventos corretos considerando a coincidência de vários identificadores na mensagem (ID de causa, ID de correlação e assim por diante).

Abordagens alternativas são um pouco mais diretas. Um seria incluir na mensagem um retorno de chamada, que pode ser chamado pelo manipulador de comandos depois que a mensagem for tratada com êxito.

Uma alternativa muito semelhante é reservar espaço na mensagem de comando para o manipulador de comandos escrever a confirmação - como o cliente já possui a mensagem de comando em questão, o circuito já está completo. Pense em " promessa " ou " futuro completável". A mensagem informa ao manipulador de comandos onde escrever a confirmação; isso sinaliza ao cliente (trava de contagem regressiva) que a confirmação está disponível.

E, claro, você tem a opção adicional de remover o middleware que parece estar atrapalhando a maneira correta de fazer a coisa certa.

Por exemplo, um usuário registrou 1 segundo antes com o mesmo nome de usuário / email

Se você estiver manipulando o registro do usuário de forma idônea, isso não seria necessariamente um erro - repetir mensagens até que uma resposta seja observada é uma maneira comum de garantir pelo menos uma vez a entrega.

Por exemplo, quando você envia um formulário de registro, é necessário verificar no modelo de domínio (WriteModel no CQRS) se ele está em um estado válido (exemplo, sintaxe do endereço de email, idade etc.)

Existem muitos tipos de validação. A validação quando você verifica a sintaxe do endereço de email e o formato de idade é um tipo de validação que um Comando pode fazer. Esta não é realmente uma preocupação do domínio. Pode parecer assim porque alguns especialistas em domínio informam essas especificações, mas você deve fazer esse tipo de validação na criação do comando. De fato, a idéia geral é fazer a validação o mais rápido possível, porque depois que um comando é criado e enviado para um BUS, é mais complicado executar ações.

Então, como você lida com um erro além do Command Bus? (Por exemplo, um usuário se registrou 1 segundo antes com o mesmo nome de usuário / email).

Esse tipo de validação é discutido muito na comunidade do CQRS, desde o início do CQRS. Onde fazer isso? É muito debatido. Pessoalmente, uso a seguinte abordagem: Antes de o comando ser enviado ao BUS, março o nome de usuário / email como tomado de maneira centralizada (isto é, uma restrição de índice exclusiva no nome de usuário / email). Depois disso eu envio o comando. A desvantagem é que, se o comando falhar, por um curto período de tempo, esse nome de usuário será usado e não usado; isso é aceitável para os meus negócios, provável para os seus negócios.

Como você sabe que o comando falhou e como você sabe o erro?

Se um comando assíncrono for rejeitado pelo Agregado por causa de um domínio invariável, algumas medidas deverão ser tomadas com a emissão de algum comando compensatório que notifique de alguma forma o emissor do comando (por exemplo, envie um email de explicação de que o comando falhou).

O problema com o email duplicado é que você não pode enviar um email porque esse endereço de email pertence a outra pessoa, é por isso que eu o checo antes de enviar o comando para o barramento.

A validação deve ser realizada em um decorador. Qualquer comando que precise de validação pode ser decorado como tal.

As validações podem ser tratadas com exceções se o retorno for anulado com o seu comando, para que possam ser atendidas com chamadas de sincronização ou assíncrona com o resultado da tarefa retornada.

Outra possibilidade é pensar na validação como um tipo de "consulta" que retornaria um resultado de validação. Execute a consulta de validação e, se aprovada, execute o comando Isso seria uma alternativa à abordagem do decorador.