You have to have some expectation that certain endpoints are "trusted". In other words if it's required that clientA application that sends CustomerMovedMessage needs to be able to be trusted then you need to test your app to make sure it's trusted (this takes discipline). When sending a command, you perform input validation and queries if necessary to validate that a command will succeed in almost all cases, when it doesn't, you do what Jason describes by Notifying something went wrong. This has design considerations also. Think of the way Amazon doesn't really confirm your order is successful until you've received an email. The other level of validation or business rules that occur when a command is processing. For this consider using sagas. The real long term value in my opinion after moving to bus style CQRS approach is that you have a bus where there are lots of events being published from several applications about meaningful things going on in the business. Then when you hear questions that say "How can I do this when this happens?" Or "How can I find out about this when these things happen?" You already have hooks into all events going on in your system and can easily add new subscribers as requests come in.
I agree Udi has a lot of great material. He also has a course that covers all these things in great detail. I highly recommend it. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-dev@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
