Eu acho que você precisa separar dois tipos de validação neste caso; validação de domínio e validação de aplicativo .
A validação de aplicativo é o que você possui quando verifica se a propriedade de comando 'text' tem entre 20 e 200 caracteres; para que você valide isso com a GUI e com um validador de modelo de exibição que também é executado no servidor após um POST. O mesmo vale para e-mail (btw, espero que você tenha percebido que um e-mail como `32.d +" Hello World .42 "@ mindomän.local" é válido de acordo com a RFC).
Então você tem outra validação; verifique se o artigo existe - você deve se perguntar por que o artigo não deveria existir, se houver realmente um comando enviado da GUI sobre como anexar um comentário a ele. Sua GUI acabou sendo consistente e você tem uma raiz agregada, o artigo, que pode ser fisicamente excluída do armazenamento de dados? Nesse caso, você apenas move o comando para a fila de erros porque o manipulador de comandos falha ao carregar a raiz agregada.
No caso acima, você teria uma infraestrutura que lida com mensagens suspeitas - elas, por exemplo, tentariam a mensagem de 1 a 5 vezes e depois a moveriam para uma fila de controle onde você poderia inspecionar manualmente a coleção de mensagens e despachar novamente as relevantes. É uma coisa boa para monitorar.
Então agora discutimos:
E os comandos que estão fora de sincronia com o domínio? Talvez você tenha uma regra na lógica do seu domínio dizendo que, após 5 comentários em um artigo, apenas comentários abaixo de 400 caracteres são permitidos, mas um cara chegou muito tarde com o quinto comentário e chegou ao sexto - a GUI não o capturou porque não era consistente com o domínio no momento em que ele enviava seu comando - nesse caso, você tem uma 'falha de validação' como parte da lógica do domínio e retornaria o evento de falha correspondente.
O evento pode estar na forma de uma mensagem em um intermediário de mensagens ou em seu despachante personalizado. O servidor da Web, se o aplicativo for monolítico, poderá escutar de forma síncrona um evento de sucesso e o evento de falha mencionado e exibir a exibição / parcial apropriada.
Muitas vezes, você tem um evento personalizado que significa falha para muitos tipos de comandos e é esse evento que você assina da perspectiva do servidor da web.
No sistema em que estamos trabalhando, estamos realizando uma solicitação / resposta com comandos / eventos em um barramento de mensagens MassTransit + RabbitMQ + broker e temos um evento nesse domínio específico (modelando um fluxo de trabalho em parte) chamado InvalidStateTransitionError. A maioria dos comandos que tentam se mover ao longo de uma aresta no gráfico de estado pode causar esse evento. No nosso caso, estamos modelando a GUI após um paradigma eventualmente consistente e, portanto, enviamos o usuário para uma página 'comando aceito' e, a partir de então, deixamos que as visualizações do servidor da Web sejam atualizadas passivamente por meio de inscrições de eventos. Deve-se mencionar que também estamos fornecendo fontes de eventos nas raízes agregadas (e faremos também para as sagas).
Como você vê, muitas das validações de que você está falando são na verdade validações de tipo de aplicativo, não lógica de domínio real. Não há problema em ter um modelo de domínio simples se o seu domínio for simples, mas você estiver executando o DDD. Ao continuar modelando seu domínio, no entanto, você descobrirá que o domínio pode não ser tão simples como foi o primeiro. Em muitos casos, a raiz / entidade agregada pode aceitar apenas uma chamada de método causada por um comando e alterar parte de seu estado sem executar nenhuma validação - especialmente se você confiar em seus comandos como faria se os validasse no servidor Web que você controla.
Posso recomendar assistir as duas apresentações sobre DDD da Norwegian Developer Conference 2011 e também a apresentação de Greg no Öredev 2010 .
Saúde, Henke