Quando falamos de CQRS, temos as consultas e os comandos. Esses comandos podem ser consumidos diretamente por aplicações, mas como expor publicamente para os clientes? Uma opção comum nos dias de hoje é utilizar o protocolo HTTP, facilitando assim o consumo pelas mais diversas linguagens e tecnologias. E quais as opções no .NET para fazermos esta exposição?
O ASP.NET é um candidato para isso, já que em sua versão core está modularizado e flexível, e assim podemos otimizar o pipeline de execução com somente aquilo que seja de fato necessário para executar os comandos. A finalidade do vídeo abaixo é exibir uma forma alternativa para incorporar os comandos do domínio no ASP.NET, utilizando o mínimo de recursos possível do hosting. Link para o código do exemplo.
Israel Aece 
Muito interessante a abordagem. Com o .Net 4.5, por exemplo, teríamos a mesma facilidade em separar os comandos dos controllers?
Boas Evandro,
Como o “core” é totalmente “plugável”, ele te permite somente incluir o que é necessário. Mas isso não quer dizer que com os controllers não dê para fazer um bom trabalho. Acredito que com algum trabalho e customização você consiga fazer algo dinâmico, pois o MVC possui bastante pontos de estensão.
Boa tarde Israel, acompanho seu blog há algum tempo e sempre achei muita coisa interessante aqui. Parabéns pelo blog!
Sobre essa abordagem de webcommands, eu achei muito interessante e fiz algumas brincadeiras tanto com ASP.NET Core e WebApi (.net 4.6.1), tudo funcionou bem, a unica diferença é que eu usei o MediatR para gerenciar os commands/handlers.
Fiquei apenas com dúvida em relação há documentação da “api” utilizado o Swagger. Para uma api padrão, o Swagger consegue mapear automaticamente as controllers, métodos, etc. Com essa nova abordagem o Swagger não saberia identificar os commands. Você também sentiu essa dificuldade? Como fez para documentar as apis?
Abraços!
Boas Wellington,
Infelizmente não combinei o Swagger com esta implementação. Será que não há como customizar a documentação para usar em conjunto? Vou ver se dou uma olhada….
Boa tarde Israel,
Eu tentei customizar o Swagger para ele entender os commands, mas achei um pouco trabalhoso tendo em vista que ele é todo baseado em Reflection, usa muito MethodInfo, já os commands não tem métodos, no máximo um construtor para receber os parâmetros de entrada. Tentei alterar o Swagger para usar ConstructorInfo mas no fim achei que era muito trabalho pra pouco benefício, pois com o Postman também consigo documentar a api, de forma mais manual mas não deixa nada a desejar, e se você tiver um servidor de homologação para a api também é possível usar o Newman (também do Postman) para criar testes de integração e testar as chamadas da api.
Abraços!