1) I know DO has made a ton of optimizations to make querying/materializing/projecting really fast. Do you think there would be a big performance improvement with the CQRS approach?

I won't expect anything beyond what CQRS and DO can separately offer here. Some performance-related features of DO may help, if you'd try to optimize for them:

• If you'd try to process a set of commands in each transaction (probably, a good idea with CQRS), DO could noticeably reduce the chattiness between application server and RDBMS. Should be attractive, since such transactions must be normally very short. I.e. if you design your processing pipeline so that each transaction runs a set of SQL commands, but not just one or two, DO will try to optimize this.
• The same about query part. DO will help to run a set of them together, if you use future queries.

But note that all these advantages play nearly the same role in regular applications as well.

2) On the read-side, when projecting onto DTOs, does DO actually materialize entities and then project onto the DTO? Or does it project directly from the data store?

Currently DO does this only after materializing the entities (if entities you populate aren't pure DTOs). We implemented this by this way because we thought about security & (possible enforcement of security rules in getters).

But we already (may be 6 months ago) decided to switch to direct materialization here. This isn't implemented yet, but if any of our clients will really need this, we'll implement this in few weeks.

3) I forgot my other questions... but I'd love to hear any comments you may have about anything related to CQRS. =)

Likely, DO must be good at producing denormalized entities as well - its prefetch & batching capabilities may help here.

If you deal with such entities (I'd think of them more as of documents), it doesn't matter much if you materialize it to DTO or not. It should be relatively heavy object containing e.g. BLOB or string aggregating the data for the whole page or form.

I'd prefer this (document-like) denormalization style. "Wide" tables are less attractive - you should care about their structure, etc.; so I'd try to deal with document-like objects instead, and leave only the columns that are interesting from the point of queries and indexes.

I also can add few notes:

• I haven't understood why you though about DisconnectedState with CQRS. I.e. DO4 uses operation sequences in DisconnectedState (and it's easy to produce such sequences by your own + serialize / deserialize them), but general, this isn't related to CQRS... Or, you mean, you need CQRS in WPF application, and query methods must return something like our MovableResult (DisconnectedState hosting Entity states + any graph with these entities) from WCF sample?
• As I wrote, I'd avoid CQRS, if possible. If you aren't sure that you need this, it's simply better to avoid this. The pattern is good only when benefits of its usage are essential. Otherwise, it's just an additional complexity - like implementing N-tier instead of 2-tier when N-tier actually isn't necessary.

Note about patterns in general

During last N years I constantly see the following: there are lot of really nice patterns, that work great in particular cases. But software design books are focused mainly on exposing the most shiny edges of such patterns - i.e. they don't show how painful it could be, if you choose the wrong one.

Let's take repository pattern as an example. It's covered in almost any book related to DAL design. On the other hand, this pattern isn't a good choice if you're going to build a a system of e.g. 1K of types with pretty complex interaction - instead of trying to reduce the complexity here by automatically persisting the state at least (DRY!), it makes you to care about this. That's obvious that big systems can't rely on explicit memory deallocations and need GC, but that's still not so obvious repository isn't good in this case, and more intelligent solution is necessary (DO, NH and EF offer them - but with their own differences).

Imagine, how I react (at least, inside) when someone asks me, "How to implement repository pattern over DO?"

The same can be said about generally any other pattern. There is no "uber cool" solution for any case; moreover, any pattern implies some associated development cost. So it's better to be very careful while making any decisions affecting on the whole architecture of your solution, such as "CQRS everywhere" option.

Or may be that's because I become pretty skeptical about ideal solutions ;) Our own experience shows that fighting for ideals in software architecture is a mistake in many many cases: you should always balance it with the implementation cost. Cost of better clearness, maintainability or extensibility is frequently too high - especially, in scope of particular project.

All I wrote here isn't much related to DO itself - it is related to other projects we run recently. E.g. we have a client, that waste may be twice more money and time on development of software exactly as it's described by Microsoft:

• they always write 100% complete specs; step aside from spec = you're shoot;
• 3-tier architecture (for web site!);
• WCF services exposing all the methods for web part there (actually, they need just few methods for integration!);
• classic ASP.NET (stuff like ASP.NET MVC isn't solid enough);
• etc.

on the other hand, they don't really care about coding guidelines, XML documentation, unit tests, CI and so on. In short, they aren't agile at all, and probably, they do understand this. But they're very fanatic about this approach, and I'm really curious who's (or what's) responsible for patching their brains this way.

And on contrary, there are projects where our developers have almost complete freedom - recently I described one of such projects. And I should say, the projects when we're free to choose the tools and approach (we normally follow agile practices) are generally more successful from the point of cost.

I also noticed that lots of successful projects (may be even with rare exceptions) were designed in worst traditions :) - i.e. frequently they're written to be brought to market as fast as it's possible. Normally it's not a big problem to make it scale well further, if there are no completely crazy mistakes. The example I immediately remembered is odnoklassniki.ru - Russian classmates.com. It was obvious it's a trash inside during its first years after launch. When they were trying to migrate it to web farm, there were absolutely funny mistakes - frankly speaking, I didn't believe they'll succeed at all. But now it's shiny - they migrated it, and it seems, finally rewrote the initial codebase almost completely. It's full of AJAX now.

So as a conclusion: think yourself, and don't be too much fanatic about patterns ;) The goal is to bring the software to market fast; how it works inside is actually a secondary question, that's interesting mainly for you. Unusual design decisions may bring very good results (immediately remembered "Beautiful code" - the solutions shown there frequently looks absolutely crazy from design point; but they worked, and worked well).

Unfortunately, this is rarely said in software design books. May be because most of them are targeted to enterprise software development (that's what we deal with as well) + large team of code monkeys (fortunately, we don't have such a team) ready to violate DRY thousand times - actually, I don't know.