I wrote about something that I called the Forgettable Payload pattern. The abstract reads “Store the sensitive payload of an event in a separate store to control access and removal.” Please read the full pattern first. In short, it’s about being able to remove sensitive information from an eventstore, for example …
Which Bounded Context owns a particular concept? One way to find out is by evolving your model until everything finds a natural place. All models are wrong, especially the early ones. Let’s look at some simple requirements, and explore how we can evolve the model over time. As we learn more about the problem we’re …
Natural Language Message Names
Embed more meaning in messages by using verbs.
Our industry has a tradition of unnatural, compact, lossy naming. This may save on typing, but costs in understandability.
Naming is hard, because we name things. If we understand the domain and have …
Migration Events in a Ghost Context
Explicitly conform to the legacy component’s model in an eventsourcing migration.
We are replacing a Legacy component with a new Eventsourced component. Besides being fully Eventsourced, the new component has a clear domain model with a well-defined Ubiquitous …
Store the outcome of a decision to guard against rule changes.
In an eventsourced system, a consumer listens to a stream of events. IT has some business logic that makes decisions, and acts upon those, for example in the form of a side effect or a new event. Because we’ve already …
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 …
Passage of Time Event
Replace cron jobs and scheduled commands, with an agnostic event to indicate the passage of time.
Many business processes involve some action or job or workload that needs to be performed at a future date. It can be a one-off action or a repeated action, it can be scheduled for a …
Design the set of Domain Events from a producer so that they can be used to rebuild the producer’s state.
Often, the events emitted by a producer, are designed haphazardly. New event types are added whenever a new feature requires them. A consumer needs to be aware of an event, …
Replace Free Queries with Domain Queries to decouple from knowledge of the server’s internals.
The word query is usually associated with database queries. There are however other ways we can query a system that we don’t perceive as a database. REST and GraphQL come to mind. I propose the …
Instead of emitting a stream of Domain Events, emit a single Summary.
A business process involves a number of steps that each produce domain events. A consumer depends on information in those events, and listens to all of them to make meaningful decisions. This in itself is perfectly …
Video for my DDD eXchange 2018 keynote in London
Software design principles aspire to be universal. And yet, when you create software, you sometimes intentionally violate principles.
You might not be able to explain why this “wrong” design somehow “feels” better. You’re applying your own, …
Video of my DDD eXchange 2017 talk in London
Video of my ExploreDDD 2017 talk in Denver
Modelling is more than knowledge management. It’s complexity management. To reduce cognitive load, you split things up, whether at small scale, in code, or in the large, such as Bounded Contexts. But if …
Video of my talk at Agile Testing & BDD eXchange 2016 in London
Video of my talk at the DDD London meetup
“Make the implicit explicit” must be one of the most valuable advices I ever got about software modelling and design. Gather around for some tales from the trenches: stories from …
Video & slides for my NCrafts talk on software metaphors.
When we model, we tend to do it for ourselves: gain understanding, capture the business language, and turn it into running code. But are we missing opportunities to do something more with our models? What if, instead of mirroring the …