Still reading the blog posts from Greg Young and derived works and one of the points which I have just got my head through is the scenario where you may have 100,000 + events for a particular object. Basically, to obtain the state for said object you need to load the aggregate from the persistence layer, and the only information you have to build up the object are the commands which were executed, so you have to replay them. Replaying 100,000+ events every time you need to load up an aggregate would be slow so the Memento pattern is used. This means that you can query the last Memento of the object and replay only the Commands that were executed after that time.
I really like the idea of this way of thinking. Another point that was made is that, say you get a bug in your system. Remedy for such bug should come in the form of a Command. When I read this, i kind of tilted my head slightly whilst reading it, but it makes perfect sense.
In previous blog posts I have mentioned that I use Agatha library on my service layers and with this I was thinking that I already have the entry point for the Command Handler. Of course I have the write and read requests so I would have to make sure that the write request handlers dealt with the domain model, where as the read request handlers dealt with the traditional DAO Repositories and Finders.
IDEA : I can imagine that the types of UIs which could evolve from this style of architecture will be sweet. I am picturing an interface where you could simply find an object from the read store, and when you select this object the UI will then load in the object from the transactional write store and possibly a nice timeline look-a-like with a property grid display of the object parallel to it. You could have a slide on the timeline and each time you changed the value of the slider, you could see the information in the property grid update.