Store the sensitive payload of an event in a separate store to control access and removal.
An Event Store is an append-only chronological database of Domain Events , so ideally we never remove any event or event data. This poses a problem when data needs to be deleted, for …
Throw Away the Key
Encrypt sensistive information in an event and delete the key.
The problem is the same as for Forgettable Payloads : some attributes of an event should not be read by all consumers, and we should be able to delete them, without touching the event store.
Encrypt the …
Segregated Event Layers
Explicitly segregate a Bounded Context’s events in visibility layers, with their own language.
The problem is the same as described in Explicit Public Events . Sometimes marking some events as public is not enough. You really need to be able to evolve the internal events …
Explicit Public Events
Mark a small subset of events as public, keep the rest private by default.
Domain Events are not only useful for communicating to other Bounded Contexts , but also for organising and decoupling code inside the Bounded Context . In CQRS/Eventsourcing architectures, this is …
Add redundant information to a Domain Event to reduce complexity in the consumer.
A consumer is interested in one event type from a producer, to react to it or report information to a user. The producer’s events are designed with a Completeness Guarantee . The event only contains the …
Today the CommitStrip featured this comic about losing touch with your users. It’s really great:
But it also made me think about the other side of this. If you are building something where your target market is someone really close to yourself then, by all means, take advantage of that. One thing that comes …