Want to thank you guys for helping me get my head wrapped around this. I have been reading and re-reading Jason's and Corey's replies and trying to apply that to my situation.
A large chunk of my users will not have email so I can't just send an email. However, I think an internal "Messaging" system would do ok. So when a command fails, I can create a new message and then have a jquery widget or something on the UI doing ajax requests to check for new "Messages". I agree that that if the validation succeeded on the client there is a small chance of it failing on the server and when it does I think the above solution would work just fine. In terms of setting up RSB and Agatha in the same host do you see any issues there? Anything I should be aware of? On Feb 9, 10:37 am, Mike Nichols <[email protected]> wrote: > You can look at the dddcqrs group too for discussions surrounding > this:http://groups.google.com/group/dddcqrs > <http://groups.google.com/group/dddcqrs> > > > > > > > > On Wed, Feb 9, 2011 at 9:04 AM, Corey Kaylor <[email protected]> wrote: > > 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
