One of the nicest things about writing publicly is that it invites real conversations. After my recent comment about Dynamic Context Boundaries (DCB) and the declining appeal of aggregates, a colleague reached out with a thoughtful challenge. Not a defensive one — the good kind. The kind that forces you to sharpen your own thinking.
Rather than debating aggregates versus DCB directly, I realised the more interesting place to look is much simpler. It’s the moment where a system is asked to change.
Every meaningful change in a system starts with a command. In the context of a policy lifecycle management system in L&H insurance sector we might have: Cancel policy from inception. Decrease sum assured. Suspend coverage. Whether that command succeeds or fails is decided by business rules. And if you listen closely to how the business actually phrases those rules, a pattern emerges.
They rarely talk about objects or ownership boundaries. They talk about what has already happened.
“Was the policy issued less than 30 days ago?” “Is it currently on risk?” “Has it already been cancelled or fallen into arrears?”
Stripped of all technical detail, a business rule is usually nothing more than this: given certain things that happened in the past, the system is now in a state that either allows or disallows this change. Those “things that happened” are events. Immutable facts.
What’s interesting is how quickly the picture changes when the use case changes. The events that matter for a cancellation from inception (CFI) are not the same events that matter when reducing a sum assured or adjusting a beneficiary. Each change has its own perspective on history. Each one cares about a different slice of the past.
There is no universally correct set of past events. There are only sets of events that are relevant to a specific decision at a specific moment. That’s what we mean when we talk about use-case-specific context.
If you look closely, this is already what we do during #EventModeling. When we define a command and the business rules that guard it, we are implicitly defining which past events are relevant and which ones can safely be ignored. In practice, that set is usually surprisingly small and sharply focused. It’s also different for almost every change we model.
Once you see this, something subtle but important happens. Each Change State building block becomes self-contained. It evaluates its own rules against its own carefully selected view of history and, if successful, emits a new immutable event. The only thing shared between use cases is facts — never mutable state.
This is where Dynamic Context Boundaries start to feel less like a radical new idea and more like a natural consequence of how the business already reasons. Invariants don’t disappear. Ownership doesn’t vanish. Complexity doesn’t magically evaporate. What changes is where that complexity lives.
Instead of being locked into a single, static consistency boundary that has to anticipate every possible future rule, the boundary emerges around the decision being made. Right where the business logic actually sits.
And yes — there is no free lunch. Some complexity moves from static model structure into explicit rule definition and event selection. But that shift mirrors reality. Businesses don’t reason in aggregates. They reason in decisions, conditions, and outcomes, grounded in what has already happened.
For me, that’s why this direction feels less like hype and more like alignment.
List of related posts:
- Post 1: We lack a shared language and blueprint
- Post 2: We can work with a small set of repeatable building blocks
- Post 3: We need a living map for the enterprise
Originally published on LinkedIn (2026-01-04): https://www.linkedin.com/pulse/when-change-state-quietly-reshapes-our-boundaries-gabriel-n-schenker-fjpbe
