Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations.
ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.
I've seen architecture presentation where it seemed like event sourcing took DDD hostage, just using it as a vehicle to sell that particular astronaut-ism. Not even a ubiquitous language...
I think part of the reason is that event-sourced needs DDD. So any story or presentation about ES, will at least mention DDD.
But DDD, by no means, needs ES.
Another part of the reason, I think, is because many other architectural patterns have taken certain concepts 'hostage'. Take for example Rails. MVC. 'Model' in Rails has a clear and distinct meaning, place and implementation. There is no way to have a bounded context, isolated domain models in Rails, without at least the terminology becoming very confusing. Having root aggregates in Rails makes all that worse, even.
What I'm trying to paint, here, is that ES naturally embraces DDD, whereas other architectures often conflict, or require effort to fit in DDD. Therefore, you'll probably find many talks about ES or CQRS and DDD, but hardly any about Actor, MVC, etc., and DDD.
ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.