This was one of the best presentations I've seen. But I have a question about the read-only/write-only repositories and the UI screen described in the presentation.

I've worked on applications which were similar to this, but we had a "reporting application" and a "data entry" application. The reporting application was eventually consistent, but the data entry application reflected the current state of the data model.  If all queries are reports and come from the report store, which is eventually consistent and the domain store is write-only, how do you show the user the data they just entered if they can't read from the store they just wrote to?

An example would be if the user navigates to a screen, updates it, changes screens, then navigates back to the screen where they just modified the data? Is this just about managing user expectations? Or do the user's changes need to live in memory/cache somewhere for a limited time?

Again, I loved the presentation. I've always believed DDD was for LOB applications with smaller scale, but after this I'm getting a better vision.

Where nice presentation. Some questions:

I have view objects in my systems as : property part is my messages and the method are the services. Some would say a service oriented architecture. When I look at DDD and the talk about not using getters and setters, then the object should only have methods. Isn't that a service object then,isn't this the same as service oriented design?

It make sense to me to only send the change of the data/state and not the state itself. But isn't this what for ex. what the database is doing in log-shipping "replication" between a online(write) database and a report(read) database. Why not use the build in technology in the database for this, why build it your self? I can see that the representation of the data can change in the write an read database, but still you can you the database replication for this. The same about undo/redo can be done with the transaction log in the database.  Why build this and have this in the "application" layer and not let the database take care of this? Would be interesting to see your view on this.

Greg, thanks for the presentation, it is all very interesting information.

When replaying your commands, do you use exactly the same code or do you disable certain things? For example, when an order is submitted with a SubmitOrder command, eventually an e-mail would be sent to the customer with an expected delivery date for example. You wouldn't want to send that every time you replay your commands.