Don't totally agree. If you use something like avro, and make sure the schema's are backwards compatible consumers can use the newer schema when they want/need.
See my answer concerning API evolution on Twitter:
Oliver Libutzki
@oliverlibutzki
@sschrass You always have to deal with API evolution, even your domain events evolve over time. By separating the event sourcing events and the public API events gives you the freedom to evolve the API in a controlled way.
I hope nobody thinks exposing your event sourcing events 1:1 to an external API is a good idea. Still evolution to the event sourcing objects should be controlled if used by multiple teams.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Don't totally agree. If you use something like avro, and make sure the schema's are backwards compatible consumers can use the newer schema when they want/need.
See my answer concerning API evolution on Twitter:
I hope nobody thinks exposing your event sourcing events 1:1 to an external API is a good idea. Still evolution to the event sourcing objects should be controlled if used by multiple teams.