Validation and Bugfixing in CQRS

I get the general concept of CQRS, but I've got a few questions when it comes to moving beyond the example code and slide decks that are out there to dealing with real world problems.

1. Validation

   When you need to do validation of a command that involves checking values from the database, what do you do? Take registration for a service, I must enter a unique email address. One argument i've heard is that its very unlikely that the user will enter a duplicate email address, so just handle it when processing the command and send them an email saying "sorry", or perhaps suggesting they reset their password. This process therefore avoids having a readmodel for the sake of the validation. But how do you deal with the duplicate case in the command handler? how d开发者_如何学运维o you know THEN that its a duplicate? check a readmodel? you might as well have used that in the first place for better usability.

2. Changes to functionality/fixing bugs

   What happens when you need to change the way a command works, or fix a bug? In the append-only philosophy, what do I do with all the old commands and command handlers? I can't rename them to _legacy and hide them away otherwise my event deserialization won't work. What elegant solutions are there to dealing with this?

Thanks

1. See http://codebetter.com/blogs/gregyoung/archive/2010/08/12/eventual-consistency-and-set-validation.aspx and the cqrs mailing list for the various discussions on this very topic.
2. Event versioning (there's no need for command versioning in the same sense as event versioning) is also discussed on the cqrs mailing list. Events are replayed to get to the current state of an aggregate, not commands. This way your functionality can evolve. There's no way to change the past, but there are ways to change the present/future. In the odd case you have to start tracking state in a different way, provide an explicit command. For new properties on events, just provide defaults as you would for a new database column. If those new values are based on state already present, then model an explicit command to precalculate them. The advantage is that you can do this asynchronously, whereas a database upgrade forces you to change the code as well. How that would work is better asked on the cqrs mailing list. One warning! Don't take on event sourcing too lightly. You can get by with just CQRS. I see people switching over to CQRS+ES when most of the time CQRS will do.

So come on over to groups.google.com/group/dddcqrs and get help. Another useful resource is cqrsinfo.com