Since publishing my last post a few minutes ago, I came across a Develicious post by Casey Charlton. He's covered what I have said in significantly more detail.
The really cool thing that he brings out, as we both refer back to some of Greg Young's architecture concepts, is that the domain/command operations could be in separate bounded context from the reporting bounded context. In fact, these two systems could have a completely different data store--something that Greg mentioned in his InfoQ video.
As an aside, the thought occurred to me that perhaps you could have the same data store for reading in both models, but writes to that data store were done through a completely different mechanism--use of a message queue. This way contention of the store could be lowered significantly. No idea on the consequences of such an move just yet, but it's something to be analyzed further.
It makes sense to have different bounded contexts and corresponding repositories for domain operations versus reporting because the needs are so different. Further, you could potentially do all domain, write-based operations in memory and, with the messaging pattern I pointed out above, you could be assured that the commands being performed would have their state persisted, but in a more scalable, asynchronous manner--without making the domain wait until the database connection was opened, written, committed, and closed.