The Event Registry

The event registry keeps track of your event types and their names for you, so you can serialize the events and be confident that they can be deserialized to the same type.

Its simplest incarnation is just a wrapper around an IReadOnlyDictionary<string, Type>, which also caches the inverse mapping. However, most of the time you'll not want to create that dictionary manually.

The AssemblyEventRegistry

The AssemblyEventRegistry takes a marker type, finds the assembly containing that type, and builds a dictionary for all types in the assembly. The constructor takes two optional lambda functions: one namer, which decides how to derive the event name from the type (default is just type.Name) and one inclusionPredicate, which decides whether or not to include the type in the registry (default is true).

The ComposedEventRegistry

The ComposedEventRegistry takes a list of other event registries, and merges them. This can be used e.g. to include event types from multiple assemblies, by wrapping multiple instances of AssemblyEventRegistry.

Note that if there are name collisions, the ComposedEventRegistry will throw an exception upon construction.

The TranslatingEventRegistry

Naming is hard. Refactoring is sometimes necessary. And sometimes you need to rename an event, even though you already have events of that type stored in the production database.

In order to handle that scenario, there is a TranslatingEventRegistry, which takes an underlying event registry and a dictionary from old to new event names and translates the event names as necessary. It supports both uni-directional translation, i.e. reading events with both old and new names while storing with the new name, and bi-directional, i.e. reading both old and new names while storing with the old name.