You're welcome, sorry for the delayed response.

>>...Events do not "trigger" ... >I don't see the difference

Yes, sorry, I'm being pedantic without context - to the uninitiated, the expression "events trigger actions" may be confusing, as it implies that events are active/actors/participants with 1:1 correspondence with reactions, omitting the recipient's agency.

>"two types of..."

...meh; I am/was both, and many other roles, but you are correct in that I hold the problem/solution domain as primary, and prefer to keep the implementation domain out of it as much as possible.

>Doesn't having it in the event payload carry the same information, just in a different place?

Yes, grouping and filtering is absolutely 100% functionally equivalent. But it is not free.

>Why?

Thanks for asking!

BookingUpdated(Reason) looks to me like an unnecessary coupling/corruption of the implementation model and domain model. This may cause additional cognitive load (user confusion/search/explanation) and possibly impact the event-routing mechanisms significantly.

For example:

* a consumer desiring only SeatReserved events will not find that as a topic. Instead, they will have to (unnecessarily) learn something about the implementation model (BookingUpdated:Reason==SeatReserved) in order to find what they want.

Slightly annoying, maybe no big deal w/better topic search or docs, just one example of a tiny unintended consequence.

* where is the selection/filtering performed? broker or consumer? Filtering is probably not free for a single-topic-per-stream implementation; something pays the price for it.

Possibly also no big deal under ordinary circumstances... but here's one way things might go wrong:

* SeatReserved events likely happen more often than the other types due to timeouts, conflicts, and retries. Ordinarily not a problem, but when hot tickets first go on sale the flood of traffic from people and bots competing for the best seats may cause SeatReserved events to increase far out of proportion with the others.

But hey, that's what autoscaling cloud services as for, right?. If the broker handles filtering, that cloud bill might be a bit scary. If consumers handle filtering, every service consuming any type of BookingUpdated event will also have to scale up too, and that bill might be terrifying. :)

With independent topics/streams/tables for each discrete concept, SeatReserved can scale independently, its traffic cannot directly affect services that do not care about it, and the names of topics and events directly reflect the problem/solution domain.

>EDA resourse repo

Excellent collection, thanks for sharing it!

While the need for "wide" events can be symptoms of other design issues, decorating base events is a good solution when they are necessary. If you really need an aggregated BillingUpdated(Reason) event, for example, you can generate it downstream and preserve the independence of the individual event types.

Offhand, I can only think of one situation where capturing the full state of the source entity in an event would be necessary: when it's ephemeral - but that sounds like a larger discussion (perhaps after enjoying a few videos from your collection).

Thanks again!