* The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain *
But to be honest, in hindsight I think it was nothing more than a drip in the ocean, and does not clarify a lot, unless you are already well versed in DDD; it's like those explanations about monads...
As for the CQRS-as-a-top-level architecture:
There are a lot of "beginner experts" and self-proclaimed thought leaders emerging, as DDD is getting more popular... (~= Agile movement)
CQRS-all-the-things is typically a phase that you go through if you are studying DDD. (I've been there, done that, got the T-shirt.)
In my personal opinion a good heuristic to detect "beginner experts" is that they prefer to use a lot of DDD lingo, and focus on the more technical aspects instead of truly trying to understand the business domain first.
Update:
Added the first paragraph with an attempt for a DDD definition.
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.
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.
To those experienced in DDD: You can do DDD without CQRS? And you can do CQRS without it being DDD too? This is not clear to me as an observer.
For example, DDD stresses the idea of an "isolated domain model" - and that has a very practical reason, being that your business rules are already complicated enough so mixing in database transactions, HTTP caching, response serialization, authorization, etc. etc., into your domain logic makes it harder to understand. You want to be able to have a conversation with a customer / domain expert where they explain something and you can adjust the code quickly to meet their needs. That's the ideal goal at least.
So some patterns enable that goal better. For example, this implies that you need some kind of data access layer pattern so that code that cares about the database is separate from code that cares about domain logic. Well, there's a million different ways to get that separation, and they have different tradeoffs, and like everything else, certain patterns become trendy. That's what's going on with CQRS. People feel that it leads to a better expression of the domain model, because creating data and querying it are often radically different from the customer's perspective.
Whether or not that goal is achieved, I'm not sure. But that's the reason people are experimenting with patterns like that, as I see it.
CQRS is associated with DDD because it is the kind of smart pattern made out of bits that the other smart patterns frown against -- like data duplication/denormalization.