Changing names == breaking things. (That’s how you end with misspelt http headers.) Coping with a new field is more interesting: new protocol version, or db schema update. What do you do of this new field your app doesn’t care about (say you are filtering/routing events: you need to lug the field around you don’t need to model it)

In classic java, does the code that implements filtering/routing events logic need to import class definitions for all types of events? I guess there are “design patterns” that make it possible to have different type of events with a common minimal set of fields to be processed by “generic” code.

It’s not about header vs payload

It’s about payload evolution

you dispatch purchase events based on amount

new version of the message comes in because of some new VAT regulation

you don’t care about the extra fields

but you need to pass them down

How do they manage it in classic Java? They add the new fields to the Event class?

Either they go with a stratified approach (discrete typed getters + generic get — possibly generic gets, one for each type: getString, getLong etc.)

which allows to not break on payload extension (because backed by a map)

or they map each message piece as a class field and you get brittle code.

What are discrete typed getters? Is it something like m.getAsString("price") ?

By discrete getters I mean getName getPrice and the like

GetAsString is a typed generic getter

Are the terms “discrete getter” and “typed generic getter” well known terms?

Nope