If it’s really that simple, why are do bible sized books written on the topic ? Why does it even need a name if it’s just common sense ?
I think the main topic and real difficultly of DDD is figuring out specifically where and how to separate out different contexts (the so-called 'bounded context' in DDD parlance).
Creating microservices is a good example. Where should the responsibility for a single microservice start and finish? What might the implications for scalability and extensibility be? What does this mean for data storage? What data will be shared or replicated between microservices and how will this be done?
Answering these kinds of questions is hard and has big implications for your teams and for your business.
It's very specific that, for instance, your domain model "should only be created by factories", though.
It's all a bit bikesheddy.
shrug maybe im reading all the wrong things but IME most DDD discussions, blog posts and books sound more like this:
https://stackoverflow.com/questions/555241/domain-driven-des...
And few delve into the real "essence" as you put it.
Event storming is one of few times, but it doesn't seem to be a core part of DDD and i found the outcome to be underwhelming.
I think most important to realize that DDD is just another tool in your toolbox, and can be used alongside all / most of the other tools you already use. Event storming can be a nice way to quickly kick off the elaboration process, should the method appeal to you.
Most non-fiction literature is like that.
Money.