What the provided answer lacks imo is that they are in most cases used both instead of 1 or the other, which seems to be the tone of the provided answer/question.
An event is something significant in your application. Let's assume your application is a Webshop.
A significant action in your webshop can be Product Purchased . When a product is purchased you need to do a lot of different steps. Putting this all inside a controller and potentially in several different places can get very messy and not clear.
So a good approach would be to use a Event called ProductPurchased . This event can have Listeners , those listeners are in this case all the steps you need to preform when a user purchases a product.
e.g.:
ProductPurchased (event)
- BillClient (eventlistener)
- GenerateInvoice (eventlistener)
- notifyClient (eventlistener)
- ...
Let's say we want to notify our client with a text-message and an email when they purchased a product.
So on the notifyClient event-listener we can create a Notification . This notification is responsible for sending a message to the client. This can be a SMS/Slack-message/Email/...
And like you mentioned both Events and Notifications can be put on the Queue or can be broadcasted.
You choose notifications when you want to send something to different channels. Mail/SMS/Slack..
If you only need broadcasting you can just use ShouldBroadcast. Just like when you only want to send a e-mail use Mail:: without the need for a notification.
Notifications are a nice way to group the same 'message' to different destinations.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…