Estou trabalhando em um aplicativo que eu adoraria fazer a transição de uma arquitetura em camadas bastante tradicional para o CQRS, por vários motivos, não menos para que ter um log de eventos robusto tornará a adição de algumas solicitações de recursos Eu posso ver indo em direção a mim trivial para acomodar.
Agora, eu tenho um problema conceitual: de cerca de 40 comandos que o usuário pode iniciar, existem três que o usuário precisa para ter certeza de ter completado com sucesso antes que a interface permita fazer qualquer outra coisa. Tudo o resto se encaixa no modelo "enviar uma solicitação, consultar o sucesso depois", exceto por esses três comandos.
Como isso é tratado no CQRS-land? Eu separo os três comandos de bloqueio para efetivamente um terceiro serviço, então tenho Comandos, Consultas e Comandos de Bloqueio? Eu tenho um processador de evento de dois estágios com um primeiro estágio de bloqueio de solicitação que só é usado para os comandos de bloqueio? A existência desses três comandos significa que toda a idéia de aplicar o CQRS é inválida? Devo apenas fingir que não estão bloqueando e pesquisando o sucesso na interface do usuário?
Tenho certeza de que isso deve acontecer em outros projetos, como isso geralmente é feito?
Ninguém nunca disse que todos, ou quaisquer que sejam, comandos devem ser assíncronos. O conceito central é separar leituras e gravações. Quando você usa comandos e eventos como o mecanismo de transporte, torná-los assíncronos é definitivamente mais fácil.
Processe isso de forma síncrona.
é mais fácil fazer uma operação assíncrona parecer síncrona, e não o contrário.
você pode usar o REST e a interface do usuário, para fornecer um diálogo modal e fornecer um retorno de chamada / pesquisa para obter êxito. Isso permitiria efetivamente que você tivesse um mecanismo para torná-lo síncrono e modal.
Parece que você tem um cenário que se beneficiaria de uma saga. Confira o que a Udi e Greg Young (habilidades) têm a dizer sobre isso.
Tags architecture ui cqrs