This afternoon I listened to a webinar with
Adam Dymitruk
,
Martin Dilger
and
Allard Buijze
from
Axoniq
about Dynamic Context Boundaries (DCBs). You can find the video link here: https://www.youtube.com/live/lvQJZ9OoE3A?si=KT9488Keg1UB0t7u

At times the discussion became very technical. Aggregates, sagas, indices, consistency, event stores. No surprise. Three engineers talking to each other.

But while listening, I kept thinking about something else.

For me, Dynamic Context Boundaries are not primarily a technical refinement. They feel like the missing link. The piece that finally allows us to speak the language of business without constantly translating everything into technical abstractions.

Business people do not think in aggregates.

They think in activities.

A claims expert in Life and Health insurance does not wake up thinking about state transitions. She thinks about the activities she is responsible for. Each activity belongs to her role. Each activity requires specific permissions. From her perspective, each activity is atomic, even if under the hood it triggers many consequences.

Take something that sounds simple: Cancel Policy from Inception (CFI).

From the outside, it looks like setting a policy to “cancelled.” From the inside, it is much more precise.

Was the policy issued? Were premiums collected? Is cancellation legally allowed at this stage? Do regulatory rules apply? Does a cancellation document need to be generated and sent?

This is where the conversation becomes interesting.

Instead of debating object graphs, we ask very concrete questions. What exactly are the business rules, in plain English? Which past facts are relevant to validate this activity? Under which conditions must it fail?

Dynamic Context Boundaries help us isolate the past business events that matter for a given activity. From those past facts, we build just enough local state to check whether the rules are fulfilled. No more and no less.

Notice what has not happened so far. We have not talked about entities, aggregates or implementation details. And yet we can reason about the system in a very precise way, together with the business.

That changes the dynamic in the room.

Compliance understands it. Auditors understand it. Security understands it. Because we are no longer arguing about attributes on objects. We are discussing permissions that are directly tied to business activities.

Roles. Responsibilities. Separation of duty.

And something remarkable happens. Business is suddenly willing to take accountability for defining roles and associating permissions with them. The permissions are no longer technical constructs. They are concrete activities people perform every day.

In my earlier posts, I wrote about the quiet cost of starting execution too early. I also reflected on why governance models often fail when they try to control structure instead of creating shared understanding.

This feels like the continuation of that thread.

When we model around business activities, grounded in past facts, governance becomes less about enforcement and more about clarity. We are no longer translating between two worlds. We are describing one shared reality from two perspectives.

Maybe Dynamic Context Boundaries are not just a modeling technique.

Maybe they are simply a better way to have the right conversation.

Originally published on LinkedIn (2026-02-12): https://www.linkedin.com/pulse/dynamic-context-boundaries-where-business-engineering-schenker-5z3oe