Best practice for naming Event Types in Event Sourcing

Question

When building an event store, the typical approach is to serialize the event and then persist the type of the event, the body of the event (the serialized event itself), an identifier and the time it occurred.

When it comes to the event type, are there any best practises as to how these should be stored and referenced? Examples I see store the fully qualified path of the class ie.

com.company.project.package.XXXXEvent

What effort is then required though if you decide to refactor your project structure?

Answer 1

After years running event-sourced applications in production, we avoid using fully qualified class names or any other platform-specific identifiers for event types.

An event type is just a string that should allow any kind of reader to understand how the event should be deserialized. You are also absolutely right about the issue with refactoring the application structure that might lead to changes in the class name.

Therefore, we use a pre-configured map that allows resolving the object type to a string and to reverse the string to an event type. By doing so, we detach the event type meta from the actual class and get the freedom to read and write events using different languages and stacks, also being able to freely move classes around of needed.