The conventional idea of “domain events” in DDD as formulated in lots of articles (such as this one, this one, and this one), seems to me like it outright violates the DDD principle of an aggregate being a consistency/transactional boundary, since the very thing this implementation apparently meant to accomplish is cramming changes to multiple aggregates synchronously and persist them as part of the same database transaction.

To quote the first article I linked to:

This pattern isn’t always applicable. If I need to do something like send an email, notify a web service or any other potentially blocking tasks, I should revert back to normal asynchronous messaging. But for synchronous messaging across disconnected aggregates, domain events are a great way to ensure aggregate root consistency across the entire model. The alternative would be transaction script design, where consistency is enforced not by the domain model but by some other (non-intuitive) layer.

Corect me if I’m wrong, but it seems like the notion of “synchronous messaging across disconnected aggregates” is just in polar opposition to the idea of an aggregate being a consistency boundary, which is fundamental to DDD, as far I understand. Yet, it looks are “domain events” are a pretty popular idea; and nobody seems to have noticed this apparent contradiction.

What am I missing?