Fundable Boundary

Two candidate boundaries are equally defensible on the domain model. One splits a funding source and needs two directors to approve any interface change. The other sits inside one budget and one approver. Within a quarter, teams will have learned which side of the line is cheap to change, and the code will move there — not from indiscipline, but because an in-boundary change ships in a sprint and a cross-boundary change waits for a forum that meets weekly with a backlog.

A fundable boundary is one whose upkeep has a payer and whose breaking changes have a single decider. The domain model says where the line belongs; the funding model says whether it will hold.

Why it matters

Boundary decay is usually blamed on discipline and better explained by decision latency. If a cross-boundary change takes 3 weeks and an in-boundary change 3 days, the organisation has priced a 7-to-1 penalty on respecting the boundary. The observable result is a shared database, a chain of synchronous calls, or logic in the wrong service, arriving within a year.

The second effect is on the designs themselves. When crossing is expensive, engineers design to avoid crossing, which produces larger and more coupled components than anyone would choose technically. A slow approval path changes which designs get proposed.

Implementation patterns

• The one-name test. Name the single person who can approve a breaking change to this interface without convening anyone. Two names means the boundary needs a funded contract and deprecation policy, or it needs to move.
• A standing run allocation behind every long-lived boundary, typically 15% to 25% of the owning team's capacity. A boundary with no budget line becomes unowned when its project closes.
• Versioned contracts where the boundary must be crossed: a published schema, consumer-driven contract tests in both pipelines, and a deprecation window with dates.
• Measure decision latency per boundary in elapsed days from request to decision, and publish it.
• Escalation with a default. If a cross-boundary decision is not taken in 10 working days, a stated default applies, which bounds the queue.

Industry example

A mid-sized retailer draws a clean boundary between order management and fulfilment. Order management is funded by the digital-commerce director; fulfilment belongs to supply chain, with its own budget and a change forum meeting weekly with six slots. The domain model is right: different language, different rates of change, different invariants.

Over four quarters about a dozen interface changes are needed, each waiting one to three weeks. Engineers start writing fulfilment-shaped logic inside order management because it needs one approval, and in production the boundary becomes a naming convention. The incident that follows — orders marked shipped that were not — is diagnosed as a data problem. It was a funding problem that arrived in the code.

Failure scenarios

• Silent re-crossing, after which the diagram stops describing the system.
• The unowned shared component. A broker or registry created inside a project has no payer after go-live; the next team forks it, and two years later there are four.
• Approval-shaped design, where components are oversized because crossing is expensive and nobody records that the shape was chosen for approval cost.
• Queue collapse. A shared forum near capacity sees waiting time rise sharply, so teams batch larger and riskier changes.
• Compliance boundary bypassed under deadline pressure, which becomes an audit finding.

Trade-offs

Aligning boundaries to budgets risks the opposite error: an architecture shaped by the current org chart, which is the one thing guaranteed to change.

The resolution is asymmetric. Derive the boundary from the domain, check it against the funding model, and treat a mismatch as a cost to be named rather than a reason to move the line. What fails is calling that cost somebody else's problem.

When not to use it

When the boundary outranks delivery speed. Regulatory separation, tenant isolation and security domains are not negotiable against convenience, and their coordination cost is part of the bill.

During an announced reorganisation, when aligning to current budget lines encodes a structure that will be gone in two quarters.

In a small organisation, where one budget makes every boundary fundable.

Interview question

Q: Two candidate service boundaries are equally clean on the domain model. One sits inside a single team's budget and approval path; the other splits two directorates. Which do you choose, and what would you do if the correct domain boundary were the one that splits them?

What a strong answer covers: that decision latency decides which boundary survives; the one-name test; the decay mechanisms (logic migrating to the cheap side, approval-shaped sizing); and for the hard case a concrete bill — versioned contract, contract tests both sides, deprecation window, escalation default, run allocation — priced as the cost of keeping the right boundary.

Quick check

Quiz: What single question tells you whether a proposed boundary will survive its first year? Name the one person who can approve a breaking change without convening anyone; two names means it needs a funded contract or needs to move.

Flashcard: Why does a boundary splitting two budgets decay even when the domain model is right? — Cross-boundary changes take weeks against days in-boundary, so logic moves to the cheap side, and the penalty also makes components larger than anyone would choose.