For the past few weeks I have been scouring the Internet investigating all things related to DDDD as well as the concepts behind Command Query Separation at an architectural level.
One of the main posts that is referenced is Martin Fowler's work on Event Sourcing. In a nutshell, the article talks about capturing each change to the application state as an object and then persisting those objects. Then, to rebuild the state of an application at a given time, you simply re-run those captured objects against your entity.
It's a really powerful concept but there were several caveats that I wanted to iron out in my head. After watching Greg's devTeach talk I was finally able to figure it out.
My problem was that, as I read the Martin's article, it sounded like he was capturing the commands coming into the object rather the state on the other side as a result of the commands. Perhaps it was the example he used that gave me this impression. From that limited perspective, Event Sourcing seemed much more difficult. Specifically, if I was re-running all of the commands against an object at a later point, but the code had changed, such as a feature change or a bug fix, wouldn't my final state be vastly different when the object was reconstituted? The short answer is yes.
As I watched the devTeach video, I realized that the messages that Greg was capturing were actually the event messages coming out of the entity which had explicit state transitions in them. These weren't the commands coming into the entity.
This is is a fundamental and critical difference. If I were to reprocess a command against the entity, I very well may have different state coming out as the underlying code changes. But when reprocessing events, the story is much, much different. In many ways, reprocessing an event message is like hydrating your entity from a database. The entity just looks at the message which says, "The ABC variable was XYZ at this point in time", and it sets the variable accordingly.
Granted, there are a few small versioning issues related to changes in your event messages, but messaging as a whole has much better guidance on how to version, e.g. with constructive rather than destructive changes.