Knowledge Crunching Doesn't Need a Room

Most people think the hard part of domain modeling is learning the patterns. Aggregates, entities, value objects, domain events, repositories — the tactical toolbox. There are books, courses, conference talks, and GitHub repos dedicated to teaching you the building blocks.

The building blocks aren't the hard part.

The hard part is the moment someone says "we approve claims" and you have to decide whether approval is a command on the Claims aggregate, a policy triggered by an upstream event, a saga that orchestrates across multiple contexts, or all three depending on the claim type and the regulatory jurisdiction.

The hard part is drawing a bounded context boundary on Tuesday that feels clean and coherent, then realizing on Thursday that an invariant you didn't consider means two things you separated actually need transactional consistency — which means they belong in the same aggregate, which means your context boundary is in the wrong place, which means the event contract you designed between those contexts no longer makes sense.

The hard part is holding six bounded contexts in your head simultaneously, knowing that a decision in Context Three depends on something you resolved in Context One, and that both cascade into how Context Five consumes events. Every boundary decision has downstream consequences. Every downstream consequence can invalidate upstream decisions. The model is a web of interdependencies, and the only way to validate it is to trace through the whole thing at once.

This is what Eric Evans meant by knowledge crunching. Not learning patterns — resolving ambiguity. Two or more people sitting with a domain until the model gets sharp enough to survive contact with reality. The patterns are the vocabulary. Knowledge crunching is the conversation.

And that conversation is relentless. It's not a meeting you schedule. It's the continuous, grinding process of someone saying "what about this case?" and the model either absorbing the question or breaking under it. When it breaks, you reform it. When it absorbs, you move to the next question. The model converges through pressure.

Here's what that pressure actually looks like in practice.

I was working through a domain specification for a system with six bounded contexts. Somewhere around the third context, the model exceeded what I could hold in working memory simultaneously. Not because the individual pieces were complex — each context was tractable in isolation. But the integration points between them weren't. The aggregate boundaries in Interpretation depended on decisions made in Ingestion. Those decisions had downstream consequences for how Structural Analysis consumed events. And Structural Analysis fed back into the gap report that could invalidate the original Interpretation boundaries.

In a team, this is where you call a meeting. Get the owners of each context in a room. Walk the whiteboard. Each person holds their slice deeply and the adjacent slices loosely. The integration points live in the conversation between people. That's the whole point of the room — to synchronize what's in six different heads into one coherent model.

The room works because it distributes the cognitive load. No one person needs to hold the full model. The team holds it collectively, and the conversation is the synchronization mechanism. When someone challenges a boundary, the person who owns the adjacent context can immediately respond with "that breaks my event contract" or "that actually solves a problem I've been sitting on." The model gets refined through distributed challenge.

Without the room, the cognitive load doesn't distribute. It stacks. Every context, every boundary, every event flow, every cascade sits in one head. And working memory has hard limits. So you do what any reasonable person does — you simplify. You make the boundary decision that feels right for the context you're focused on, without fully tracing the cascade to all six contexts. You defer the integration questions. You move forward.

And then you discover the problems during implementation, when the cost of correction is highest. Exactly the failure mode DDD was designed to prevent.

This is the structural problem underneath the solo-builder problem I wrote about last time. It's not just that solo builders lack the team. It's that the specific thing the team provides — distributed cognitive load under continuous challenge — is the mechanism that makes domain models converge. Without it, models don't get wrong. They get shallow. They survive the easy questions and collapse on the hard ones.

Without it, models don't get wrong. They get shallow. They survive the easy questions and collapse on the hard ones.

So the actual question isn't "how do you do DDD alone." It's "how do you recreate the conditions under which ambiguity gets resolved." You need sustained challenge across the full model. You need a counterpart that holds the complete state while you interrogate specific corners of it. You need someone who asks "what happens when step three fails after steps one and two have already committed?" at the exact moment you're tempted to model a saga as a simple policy because the simpler pattern is faster to think through.

This is what I discovered — accidentally, honestly — when I started using AI as a domain modeling collaborator. Not a code generator. Not an architecture advisor. A collaborator in the Evans sense: a counterpart in the knowledge crunching process.

What surprised me wasn't that it could discuss DDD patterns. Any LLM can recite the difference between a saga and a policy. What surprised me was what happened when the model got large.

When I challenged a boundary decision in the third context, the AI didn't respond to that question in isolation. It held the full state of all six contexts — every aggregate, every event flow, every policy trigger — and surfaced the cascade. "If you move this aggregate, it breaks this event contract in Context Two, which means this saga in Context Five needs to change from choreography to orchestration." The full trace. Immediately. Without being asked to check.

No human collaborator does that. Not because they aren't capable, but because working memory has limits. In a team of six, each person holds their context deeply and the adjacent contexts loosely. The integration points live in the gaps between people's heads. That's why you need the room — to synchronize those gaps. The AI doesn't have gaps. It holds the full model at the same fidelity across all contexts, all the time.

This changed the nature of the collaboration in a way I didn't anticipate.

In a team, challenging a decision carries social cost. You're questioning someone's judgment. Even in healthy teams, there's friction. So you pick your battles. You challenge the decisions that feel most wrong and let the merely suboptimal ones pass. That's rational. You can't challenge everything.

With an AI collaborator, the cost of challenge drops to zero. Every decision gets pressure-tested. Every boundary gets interrogated. Not once — dozens of times, across dozens of decisions, without anyone getting tired or defensive. You end up in genuine friction: you challenge a boundary, the AI pushes back with a structural argument, you counter with a domain argument, the model sharpens. That cycle repeats until the model absorbs the pressure or you explicitly decide to defer.

I'll give you one specific moment that stuck with me.

The specification had a multi-step refinement flow. I'd modeled it as a policy — "when this event arrives, do this thing." Quick. Clean. Easy to reason about. The AI challenged the classification and walked through a failure scenario: what happens when step three fails after steps one and two have already committed? A policy doesn't track state across steps. A policy doesn't compensate for partial completion. That's a saga.

I knew the difference between policies and sagas. I'd implemented both. But in the flow of modeling, without someone in the room to ask "what happens when it fails?", I'd reached for the simpler pattern. Not out of ignorance — out of the natural tendency to simplify when there's no one applying counter-pressure in real time.

That single challenge — one question about a failure path — changed the specification's reactive architecture. And it was the kind of question that should surface during modeling but often doesn't — even in teams.

This is the part that's uncomfortable to admit. The room doesn't always work. Teams have the potential to provide sustained structural challenge, but in practice, that potential goes unrealized more often than anyone wants to acknowledge. Meetings run long. The whiteboard session covers the happy path and someone says "we can figure out failure handling during implementation." The saga-versus-policy distinction doesn't get raised because the person who would have caught it is focused on their own context, or didn't attend, or didn't push hard enough because the meeting was already over time.

And then someone discovers the problem six weeks into implementation, when step three fails and steps one and two have already committed and there's no compensation logic because nobody modeled the failure path. The rework isn't just code — it's architecture. The cost multiplier is enormous. That's the painful reality of DDD in practice: the methodology is designed to surface these questions early, but the delivery mechanism — team collaboration under time pressure — frequently lets them through.

The methodology is designed to surface these questions early, but the delivery mechanism — team collaboration under time pressure — frequently lets them through.

Over the course of that specification, I resolved over thirty structural gaps through this kind of back-and-forth. Not gaps the AI found on its own — gaps that surfaced because the collaboration forced both sides to be precise. The AI would propose a boundary. I'd reject it because it violated a domain invariant I hadn't articulated yet. The act of articulating it refined the model. The model converged through pressure. Exactly the way Evans described. Just without the room.

I want to be honest about what this isn't. It's not a replacement for a team. A team brings diverse domain expertise — people who've lived inside a business for years and carry implicit knowledge no specification captures. A team brings political context about organizational boundaries that should inform where bounded contexts land. A team brings the kind of cross-functional challenge where a product owner says "that's not how the business works" and the model changes in a direction no architect would have found alone.

But for the structural discipline — the systematic challenging of every boundary, every classification, every event flow against the full model state — an AI collaborator with perfect recall and zero social cost of disagreement is more effective than I expected. Not because it knows the domain. Because it doesn't let you skip the hard questions.

The conversation is different than what anyone expected. It's not "AI generates domain models." It's "AI recreates the forcing function that makes domain models converge."

It's not "AI generates domain models." It's "AI recreates the forcing function that makes domain models converge."

The methodology still works. The collaboration just looks different.

This is the second post in a series on rigorous domain modeling without a team. Next: what a decade of DDD practice missed — and how a structured assessment surfaced it.