After my last post on aggregates and Dynamic Context Boundaries (DCB), a colleague followed up with a thoughtful question that kept lingering with me. Not because it challenged the mechanics of DCB — but because it went straight to the heart of architectural autonomy.
The question, in essence, was this: What happens when the facts needed to make a decision live outside the domain that needs to make it?
This is where many architectural discussions become abstract very quickly. So instead of answering it in terms of stores, tags, or deciders, I’d like to step away from software for a moment.
Imagine a company with no computers. Just departments, filing cabinets, paper records, and people.
Let’s say the policy administration department needs to cancel a policy. To do so correctly, they must apply a set of business rules. One of those rules depends on whether a premium payment has been made — information that lives in accounting.
What do they do?
They have options.
They could pick up the phone and call accounting every time they need to know. Or — much more realistically — they agree upfront that whenever a payment is made, accounting sends a notice. That notice gets attached to the policy file and becomes part of the material policy administration uses to do its job.
Notice what doesn’t happen.
Policy administration does not take over accounting. They do not gain the authority to decide whether a payment is valid. They simply receive a fact that is relevant for their own decision-making.
This is how businesses actually work.
And this is the part that often gets lost when we talk about aggregates, deciders, or even domains: businesses don’t reason in aggregates. They reason in decisions, conditions, and outcomes — grounded in what has already happened.
Now, back to software.
A common concern with DCB is that if events are accessible across boundaries — for example via shared storage or tagging — coupling becomes tighter and more dangerous. That policy might “silently” start depending on payment events without anyone noticing.
That concern is valid — but it’s also based on a subtle assumption: that DCB implies a global event soup where everything is fair game.
It doesn’t.
DCB does not say “all facts are yours.” It says: a decision defines which facts are relevant.
The crucial step — just like in the paper-based company — is translation.
When an external event occurs (a payment is made), it is not consumed raw by the policy domain. It is translated into a local fact that has meaning inside that domain. “A premium was paid for policy X.” Nothing more. Nothing less.
Ownership does not move. Authority does not leak. Only the minimum necessary fact crosses the boundary.
This is not fundamentally different from classic event-driven integration — but the intent is different.
Traditional approaches tend to start from ownership containers: Which aggregate owns this? Which domain publishes what? DCB starts from the decision: What must be true for this action to be valid?
That shift matters.
Because once you start from the decision, you realize that boundaries don’t disappear — they become explicit. Translation becomes a first-class concept instead of an implementation detail. And coupling is no longer hidden in infrastructure or message choreography, but visible in the business logic itself.
So when asking, “What does DCB give me that a decider plus event-driven integration doesn’t?”, my answer is this:
DCB gives you a language to talk about facts without moving ownership, and decisions without dragging entire domains into the room.
And that, in my experience, is much closer to how businesses actually think.
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
- Post 4: When “change state” quietly reshapens our boundaries
Originally published on LinkedIn (2026-01-05): https://www.linkedin.com/pulse/where-does-domain-get-facts-needs-make-decision-gabriel-n-schenker-bk7re
