Being event-driven and using event sourcing with an event store has become the new "factory, repository, entity, value object" which has put the wrong focus on DDD for years.
What do I mean about this? Well, DDD has been around us for a while and I do believe one big issue with it is the amount of focus the tactical patterns has gained. I do understand why. Those parts are what's easy to understand and relate to as a programmer. It's much more concrete and less abstract. While the more important parts of DDD, the strategic parts, is more abstract and requires a deep understanding of the business and the domain where you are supposed to be delivering value within. To master this, it requires interaction with the business. Scary right? So yes, I can understand that techy people focus on factories and repositories etc. But what does this have to do with event sourcing?
I do believe the same is often the case with event sourcing. A technical decision is made to store every change in the domain as an event and doing so without paying attention to the events. You become event-sourced, but not event-driven. You don't pay attention to the cause of the event. The process behind the event.
In any event-driven system, where you say you work with domain-events, you should be able to generate a map with all events and their causes and present that to the business and they should be able to understand it and preferably say:
"Yep, this is our intended process. No doubt about it."
If you instead first and foremost focus on the event sourcing part: storing changes as events in time series fashion; I would say, you increase the risk of instead getting something like:
"What's these create and delete stuff? What's this 'FooChanged' thing?"
So, if your intentions are to event source "business events", ensure you do understand the process and align the events to it.
Cheers,
//Daniel