I have tried to pick a few common CQRS questions and supply my own answers:
1) I'm really missing some definition of WHEN to use CQRS. Collaboration, I know, but 90% is collaboration in my book. A Customer table for example. And Orders, Invoices and shipping tables. Can those be accessed and edited by more than one user? Yes - well there's collaboration!
The point here is that, yes, they can be edited by more than one user, but are they really? How high is the probability of having more than one user updating the same Customer simultaneously? I would say close to zero. The same goes for the other entities.
Sure, all of the users are working together to keep the customer table in sync with reality, that is collaboration. But it is not collaboration in the way of working on the same shared resource!
But we still need to handle that 0.001% change of simultaneous updates! Sure - so add a simple version check (first update wins, second update gets a notification). That is not CQRS One Way Commands - that's plain old synchronous and locking database updates.
So when are we collaborating on shared resources and expecting lots of simultaneous work? Good question (and I do not have a good answer). The fact that so few examples exists indicates that CQRS is something which is not normally required.
2) What about the fact that many implementors feel that things are getting much more simple just by having read and write separation. Isn't that a reason in itself to use CQRS?
You can separate reading and writing without CQRS and eventual consistency. All you need is two different code bases working on the same database table. Very low tech. Maybe throw in multiple database views to support more or less complex queries.
3) But having different read and write databases helps scaling out.
Yes. So does plain single-write-master/multiple-read-slave database replication. If scaling out the query part is your problem then use master/slave on the database level. If scaling out writing is your problem then look into CQRS for that particular use case which requires it!
Scaling out writing is required if you have lots of issues with database deadlocks and timeouts due to intensive locking of the database. This won't happen if all your users do, is to work on different entities all the time.
4) Adding some repository and an event store might be hard the first time, but after that it's really simple. Right?
In my little experience - No. But I may certainly be wrong and have used the wrong tools. In theory it is simple, yes, in practice, no. It adds complexity - not that much, but enough add friction to your project. If your are reading this for some advice on CQRS - well, you might just have experienced that friction and started wondering why.
CQRS adds extra time spent on infrastructure for simple problems, when you should be spending time on complex problems, while keeping simple stuff, well, simple. See also my previous post: http://soabits.blogspot.com/2011/09/why-cqrs-may-not-be-answer-you-are.html.
Please, go ahead and use CQRS! I am not saying "no, do not" (who am I to do that?) - I am just sharing my experience.