What they don’t tell you about event sourcing is an interesting read page 
> Great article. Having spent the last several years designing and maintaining ES systems, I think these are all the same caveats I give to clients who are considering building and ES system today. The devil’s in the details, and chief among those is the design and schema of your events. Granularity is a greatly underappreciated factor—an inexperienced developer using ES the first few times will almost always reproduce a CRUD system using event messages, which leads to a highly frustrating experience for most. I’m still a big believer in the architectural tool, but like most tools, it needs the right problem to be effective.
Earlier we developed a CRUD application on a navigational database. A large scale ERP application without SQL relationships with over 100,000 customers in 40 countries. All the relationships were in code. And the master domain model was in a few a core developers heads. Now we consider developing a system based on CQRS with two models. One for writes and another for queries... we need to think about aggregates and the inconsistency window.
Also, see