In my recent posts I’ve been using Life & Health insurance as a concrete example — not because the problem is specific to insurance, but because it gives us a shared, real-world context. I’ll do the same here, especially for readers who may not have followed the whole series.
What I find interesting in this discussion is how quickly we drift into technical language: aggregates vs. DCB, one event store vs. many, deciders, transactional consistency. Those are important questions — but they are secondary. They are implementation choices. The more fundamental question lives at the business level.
So let’s rewind to a world where no software exists yet.
In a traditional L&H insurance organization, Policy Administration and Payments (as part of Finance) are separate departments. Each has its own authority, its own responsibilities, and its own records. Payments knows whether money was received, reversed, or disputed. Policy knows whether coverage is active, suspended, or cancelled. No department “owns” global state. What they own is decision-making authority.
Policy (administration) does not need to own payment state in order to enforce its invariants. What it needs is credible evidence to make its own decisions. Evidence such as: “Premium for invoice X was received on date Y.” Or later: “That payment was reversed due to a chargeback.”
Those are not internal implementation details. They are business statements — things one department is willing to publish so that other departments may rely on them.
Now consider a very common L&H scenario: a policy is activated after premium payment, coverage starts, and weeks later a chargeback arrives. Payments publishes a new fact: the payment was reversed. Policy administration now has to decide what that means. Do we suspend coverage? From when? Is there a grace period? Are there claims already paid that now need recovery? All of those are Policy decisions, governed by Policy rules, not by Payment’s internal state.
This is where the discussion often gets stuck on “state ownership” or “consistency models”. From a business perspective, those are the wrong nouns. What really matters is:
- Who is allowed to declare a fact?
- Who is allowed to act on that fact?
- And who is accountable when the decision turns out to be wrong?
If we start from those questions, boundaries become much harder to cut incorrectly.
Whether Payments publishes its facts via integration events, reports, ledgers, or a shared log is secondary. What matters is whether those publications are explicit, intentional, and safe for others to rely on — as opposed to internal working state that is not meant to leave the department.
This is also where, for me, the value of a more decision-centric view (often labeled DCB) shows up — not as a rejection of aggregates, but as a shift in focus. Instead of starting with “what is the Policy aggregate and which invariants must it protect transactionally?”, we start with “which decisions does Policy make, and which facts does it need to make them responsibly?”
When you do that, the modeling naturally aligns with how the business already works: independent decision makers, shared evidence, delayed discovery of reality, and clear responsibility when things change.
And once you see it that way, the technical debate becomes much calmer — because the business boundaries are no longer inferred from data structures, but from authority and accountability.
That, at least, is the lens I find most useful — especially in complex, regulated domains like Life & Health insurance.
Prior posts in the series:
- 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
- Post 5: Where does a domain get the facts it needs to make a decision?
Originally published on LinkedIn (2026-01-06): https://www.linkedin.com/pulse/boundaries-follow-decisions-data-gabriel-n-schenker-prjje
