Would it be better to separate RSB and Agatha to their own host process? On Feb 9, 11:00 am, Joe <jyoung1...@gmail.com> wrote: > 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 <nichols.mik...@gmail.com> 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 <co...@kaylors.net> 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 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.
-- 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.
