I have been studying DDD and have been experimenting with Event Sourcing as a storage mechanism.
Prior to this (mostly CRUD-style applications with anemic data models stored in relational DBs), a "best-practice" I have tried to keep in mind is to decouple my data model from any persistence concerns.
However, I have been struggling to wrap my head around how to do this with Event Sourcing. It seems that my domain model objects need to know about events and generate them themselves, and know how to reconstruct their state from a stream of events.
The only way around this I can think of is for my repositories to reconstruct domain objects from events, and then do some elaborate change detection to generate resulting events. This seems like it would be unnecessarily complicated and error-prone, as well as resulting in domain logic living in or being duplicated in the repository classes.
Or is my thinking about this all wrong and I should consider events as part of the domain model? This way, domain objects generating events and reconstructing state from events makes a lot more sense, and then storage & retrieval of events would be a persistence concern and be implemented outside of the domain layer.