The Bounded Context Is the Scope the Agent Actually Needs

2026年8月28日3 次浏览来源:Dev.to阅读原文

Originally published at tddbuddy.com.

Related reading: The Coordinated Rename Is the Agent's Most Dangerous Refactor named the vocabulary-collapse failure mode; this post pins the scoping primitive that prevents most of it.

The Contract Test Is the Only Witness the Agent Cannot Author covers the seam between contexts.

The *Vocabulary Is the Product arc (Agents Amplify Whatever Vocabulary They Find, Product Literacy Is the New Core Engineering Skill) frames the asset the scoping protects.* The agent given the whole repo consolidated three domains into one and called it cleanup.

That is the failure mode this post is about.

The agent was working on a feature in Billing.

On its way through the codebase it noticed that was defined three times, in Billing, in Support, and in Identity, with overlapping fields and slightly different shapes.

The obvious cleanup was to unify them.

The unification landed in a two-hundred-file PR that renamed types, updated call sites, migrated database schemas, and adjusted API contracts.

Tests passed.

Code review skimmed the diff.

The domain distinctions the three contexts had held for years were gone.

Two weeks later, a nightly job that iterated over anything with a payment method started charging customers who had never bought anything, because the merged type included support-only records now indistinguishable from the billing ones.

The problem is not that the agent was wrong on its own terms.

The problem is that the agent had access to a scope its incentive gradient was structurally hostile to.

Given a whole repo, an optimizer trained on consistency will consolidate.

Consolidation across boundaries that existed to be kept apart is not cleanup.

It is the collapse of the invariant those boundaries preserved.

The Domain-Driven Design bounded context has been sitting in the literature for two decades as the answer to exactly this problem for humans.

It is now the scoping primitive that keeps the vocabulary the team owns from being consolidated by the tool the team hired.

The Whole-Repo Agent Is a Cross-Context Bulldozer Given free rein, the agent's incentive is uniformity.

That single sentence is the whole diagnosis.

An agent working across a repo with two names for two concepts sees drift and offers to fix it.

An agent working across a repo with one owner in Billing, another in Support, and a third in Identity does not see three ownership boundaries.

It sees three near-duplicate implementations that could obviously be consolidated.

The consolidation reads to the agent as an improvement.

It reads to the team as a domain regression, but the team is not in the loop at the moment of the consolidation.

The agent is.

Uniformity across bounded contexts is not cleanup.

It is the collapse of distinctions the contexts existed to preserve.

A codebase whose Billing and Support contexts share a type is a codebase where a Billing change can silently affect Support and vice versa.

The two teams that owned those contexts now share ownership of every field on the merged type.

Every decision about the shape of in Billing is now also a decision about the shape of in Support, whether either team wanted it or not.

The coupling is a design choice the teams did not author.

The agent authored it, at generation speed, in a PR that read as boilerplate.

The failure mode is not that the agent generates bad code.

The code compiles, the tests pass, the diff looks clean.

The failure mode is that the agent had scope over decisions the team never delegated.

Scope is a design choice.

It has been treated as an environmental default.

DDD Solved This For Humans Two Decades Ago Bounded contexts, ubiquitous language within each, translations at the boundary.

The pattern is durable because it names the failure mode explicitly.

A bounded context is a scope within which a set of terms has consistent meaning.

Inside Billing, means a party with a payment method and a subscription status.

Inside Support, means a party with an issue history and a

分享
Baike.dev

baike.dev helps you discover great languages, frameworks, databases, DevOps and cloud-native tools.

Quick links

About

Contribute

Found a great developer tool? Share it with the community.

Submit a tool
© 2026 baike.dev Developer EncyclopediaUpdated daily · Discover great developer tools