Foer the naming, i think it depends a bit on what you do. If your app hinges around sending events out, it might be easier to do codereviews and spot whats going on, with the different suffixes.

If you the only events you have, are domain events, then it doesnt matter as much.

In the case of having to notify something outside of the application (out of band processing), the 2 events would probably exist in different projects.

With the blogpost in question, the EventHandler would feasibly be living in the application layer (if we are going for tiered architecture), and its the EventHandlers job to tell rabbitMQ whatever needs to happen (I have a blogpost coming up around the outbox pattern, which builds on domain events for this exact reason). Regardless, the RabbitMQ event would live in the ApplicationLayer (or at least a different project than the Core domain). The DomainEvents handler is triggered and the handler does whatever it needs to do.

We are still within the transaction and eventclients rarely have a rollback feature, so you would keep it at an arms length with some kind of outbox pattern or job runner (hangfire, quartz or some other job runner).

This way you persist any outbox related functions during the transaction (which is fast), the job runner will then take care of notifying RabbitMQ.

Change => Core => DomainEvent => Handler => Outbox => RabbitMQ.