I'm not advocating for CQRS or any of that, I've personally never used it on a project. But, the reason that architectures are associated with DDD is that DDD is fundamentally a philosophy or an idea. Certain software designs achieve that philosophical ideal better than others.
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.
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.