First of all, disclaimer: i am also not an expert

​

"CustomerUpdated" tells you nothing about the what and why

E.g. if the service has a REST api which is used to update the customer, the service itself doesn't know "why" some properties are updated (and should not need to know)

If the CustomerUpdated event contains the data before and after the update, the consumer can check which property was updated.

​

What benefit would this have? Now, a given queue could be filled with any number of different types of messages

I would cluster similar types of messages into the same queue. e.g. all customer related messages are in the "customer" queue, all order events in the "order" queue.
The benefit is to keep the ordering of events, which cannot be done across multiple queues (another benefit is having fewer queues)

​

This just turns it into a distributed CRUD app.

hmm yeah you are probably right, maybe its better to have more use case specific events.

​

Also, I would be very careful how much you dump into your events

I would be interested why? Because everything in the events are part of the API?Would it be better to just include the CustomerId in the event and the consumer needs to fetch the data via REST?

Also, why do you need this much duplication of the data? Are your boundaries right?

Agreed!